> 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

Reply via email to