public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Anbazhagan, Baraneedharan" <anbazhagan@hp.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>
Subject: Re: SmmCommunicationCommunicate question?
Date: Thu, 13 Oct 2016 11:07:49 +0200	[thread overview]
Message-ID: <b8f4761f-7840-da08-34ae-3db987191209@redhat.com> (raw)
In-Reply-To: <AT5PR84MB0276A78E6796B2D33429A9F3BADC0@AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.COM>

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.

Thanks
Laszlo


  reply	other threads:[~2016-10-13  9:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13  3:40 SmmCommunicationCommunicate question? Anbazhagan, Baraneedharan
2016-10-13  9:07 ` Laszlo Ersek [this message]
2016-10-13 12:46   ` Paolo Bonzini
2016-10-13 13:20     ` Anbazhagan, Baraneedharan
2016-10-13 23:52       ` Ken Taylor
2016-10-14 12:36         ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b8f4761f-7840-da08-34ae-3db987191209@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox