From: "Anbazhagan, Baraneedharan" <anbazhagan@hp.com>
To: Paolo Bonzini <pbonzini@redhat.com>, Laszlo Ersek <lersek@redhat.com>
Cc: "edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>
Subject: Re: SmmCommunicationCommunicate question?
Date: Thu, 13 Oct 2016 13:20:11 +0000 [thread overview]
Message-ID: <AT5PR84MB0276679980605CED063E0C8EBADC0@AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <1c6dc322-d226-4146-e38b-5aa280659ce5@redhat.com>
> From: Paolo Bonzini [mailto:paolo.bonzini@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.
next prev parent reply other threads:[~2016-10-13 13:20 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
2016-10-13 12:46 ` Paolo Bonzini
2016-10-13 13:20 ` Anbazhagan, Baraneedharan [this message]
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=AT5PR84MB0276679980605CED063E0C8EBADC0@AT5PR84MB0276.NAMPRD84.PROD.OUTLOOK.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