From: "Cohen, Eugene" <eugene@hp.com>
To: "Kinney, Michael D" <michael.d.kinney@intel.com>,
"Gao, Liming" <liming.gao@intel.com>,
Laszlo Ersek <lersek@redhat.com>,
"edk2-devel@lists.01.org" <edk2-devel@ml01.01.org>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
"Andrew Fish (afish@apple.com)" <afish@apple.com>
Subject: Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services
Date: Mon, 10 Oct 2016 20:11:07 +0000 [thread overview]
Message-ID: <AT5PR84MB02913B12360CCA49236C037FB4DB0@AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <E92EE9817A31E24EB0585FDF735412F5648223F9@ORSMSX113.amr.corp.intel.com>
Mike,
> Can you provide examples in EDK II today where the same GUID Value
> and Structure definition
> are used in both the UEFI Handle Database and the SMM Handle
> Database.
The example exists in our internal code right now. We have two platform families: one with SMM and one without. We have a library, originally developed as a DXE library, that use a protocol to determine a secure boot policy setting. This library is linked against our variable driver. In our non-SMM system the variable driver runs as a Runtime DXE component and the policy protocol referenced is published in the Boot Services protocol DB. In our SMM system the variable driver runs in SMM and the policy protocol is published in the SMM protocol DB. The protocol is identical and uses the same GUID. So in this scenario we don't install the protocol simultaneously in both environments, rather we have different platforms where the protocol resides on one side or the other. Since this protocol is really simple (it's not using events, TPL or depending on UEFI boot services stuff) it works well for this model.
> I am aware of cases where an SMM Driver looks for protocols in the
> DXE Handle database,
> but I don't think your proposed lib would cover that case.
Correct - in our usage we are trying to discourage the cross-pollination of SMM and DXE in this way since security minded people get nervous when SMM executes outside of the secure sandbox.
Thanks,
Eugene
next prev parent reply other threads:[~2016-10-10 20:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-30 14:13 RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Cohen, Eugene
2016-09-30 14:25 ` Laszlo Ersek
2016-09-30 16:36 ` Cohen, Eugene
2016-09-30 16:41 ` Tim Lewis
2016-09-30 16:51 ` Cohen, Eugene
2016-09-30 16:55 ` Tim Lewis
2016-09-30 17:02 ` Cohen, Eugene
2016-09-30 17:44 ` Laszlo Ersek
2016-09-30 22:04 ` Cohen, Eugene
2016-10-09 1:49 ` Gao, Liming
2016-10-10 15:24 ` Cohen, Eugene
2016-10-10 15:54 ` Kinney, Michael D
2016-10-10 16:23 ` Cohen, Eugene
2016-10-10 17:50 ` Kinney, Michael D
2016-10-10 20:11 ` Cohen, Eugene [this message]
2016-10-10 20:39 ` Kinney, Michael D
2016-10-11 15:17 ` Cohen, Eugene
2016-10-11 16:37 ` Kinney, Michael D
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=AT5PR84MB02913B12360CCA49236C037FB4DB0@AT5PR84MB0291.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