SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support)

Dr. Greg greg at
Mon Jun 3 09:12:06 UTC 2019

On Thu, May 30, 2019 at 02:36:01PM -0700, Sean Christopherson wrote:

Good morning, I hope everyone had a pleasant weekend.

> Assuming MRENCLAVE generated by Graphene or any other hosting scheme
> are stable[1], then avoiding EXEC<whatever> means the user can
> effectively whitelist what enclaves are runnable by Graphene, even
> if the kernel doesn't implement security_enclave_create/init().
> I agree that it probably isn't all that important, it's more of a
> "why not" argument, i.e. what is gained by not using sigstruct as a
> proxy?
> [1] What in the world is being attested if MRENCLAVE isn't stable?

The cryptographic identity of the entity that signed the enclave and
generated the SIGSTRUCT.

At the risk of being the monotone in the choir, any relevant SGX
security controls require verifying the identity of whoever signed the
identity characteristics (SIGSTRUCT) of the image that initiates the
execution of an SGX TEE.  Other then verifying the initial execution
image, the MRENCLAVE value isn't all that relevant.

This issue is further evidenced by the fact that sealing data to an
enclave uses the MRSIGNER variant of ENCLU[EGETKEY] key derivation.

The current work on LSM controls seems to focus on the identity of the
entity that is requesting the image to be loaded rather then who
actually signed, and presumably authored, the code.  As I have
previously noted, with SGX2/EDMM, a platform owner may not even have
any visibility into the code that an SGX TEE may ultimately load and

Any security relevant LSM control in this space has to focus on
providing the platform owner the ability to take action based on the
contents of the SIGSTRUCT of the initiating image.  In addition to the
identity of who is requesting the image to be loaded.

Have a good week.

Dr. Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg at
"Experience is something you don't get until just after you need it."
                                -- Olivier

More information about the Linux-security-module-archive mailing list