> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo 
> Bonzini
> 
> On 13/10/2016 11:07, Laszlo Ersek wrote:
> >
> > Instead, once the first CPU enters SMM, it brings all the other CPUs
> > into SMM as well, where they will be executing known, secure code --
> > i.e., the first CPU to enter SMM forces the other CPUs to temporarily
> > abandon any (possibly malicious) code the runtime OS may have prepared.
> > Only *then* will the verification of the communication buffer commence.
> > If the malicious code managed to race the unpriv part of the service
> > successfully, now the privileged part will catch that, undisturbed.
> 
> Even this is not strictly necessary if you can set aside some memory in SMRAM 
> for a
> copy the communication buffer.  Then you can do:
> 
>    tmp = comm buffer size
>    if tmp > sizeof(privileged buffer)
>        return error
>    copy tmp bytes from comm buffer to privileged buffer
> 
> and not look anymore at the buffer provided by the user.
> 
> Of course, "bring all CPUs into SMM" can double as a poor man's mutex, so 
> there
> may be reasons to do that anyway.
> 
> Paolo

Am thinking in BDS phase - if a module have periodic callback and uses 
SmmCommunicate within the callback, then it could potentially overwrite those 
gSmmCorePrivate pointer while another module trying to use SmmCommunicate.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to