> 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