On 10/13/16 05:40, Anbazhagan, Baraneedharan wrote:
> Whether TPL needs to be raised before setting CommunicationBuffer and
> BufferSize in gSmmCorePrivate to avoid a callback overwriting those
> values before triggering SW SMI?

I don't think so. The contents of the communication buffer is untrusted
(it is passed in from the unprivileged side to the privileged side), so
the SMI handler (running in SMM) has to do full validation /
verification anyway.

Another way to look at this is the following: assume that the runtime OS
calls a variable service on one processor. That variable service has an
unprivileged part (which formats the request in the communication
buffer, and triggers the SMI), and a privileged part (the code that
validates and serves the request in SMM). Now assume that the runtime OS
deliberately races, on another processor, with the unpriv variable
service code that runs on the first processor; i.e., the second CPU
tries to tamper with the communication buffer just in the time window
that you describe.

There's nothing that the unpriv variable code running on the first
processor can do against this.

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.

edk2-devel mailing list

Reply via email to