> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> 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
> may be reasons to do that anyway.
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