Re: [RFC PATCH v4 00/12] security: x86/sgx: SGX vs. LSM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/9/2019 6:28 PM, Dr. Greg wrote:
On Mon, Jul 08, 2019 at 10:29:30AM -0700, Sean Christopherson wrote:

Good evening to everyone.

That being said, we can do so without functional changes to the SGX
uapi, e.g. add reserved fields so that the initial uapi can be
extended *if* we decide to go with the "userspace provides maximal
protections" path, and use the EPCM permissions as the maximal
protections for the initial upstreaming.

That'd give us a minimal implemenation for initial upstreaming and
would eliminate Cedric's blocking complaint.  The "whole mess" of
whitelisting, blacklisting and SGX2 support would be deferred until
post-upstreaming.

Are we convinced the 'mess' will be any easier to clean up after the
driver is upstreamed?

The primary problem is that we haven't addressed the issue of what
this technology is designed to do and its implications with respect to
the kernel.  As a result we are attempting to implement controls which
we are comfortable with and understand rather then those that are
relevant.

I don't think it's about easier or harder to clean up the mess, but a divide-and-conquer strategy. After all, SGX and LSM are kind of orthogonal as long as SGX doesn't compromise the protection provided by LSM.

Let's step back and look at what started this lengthy discussion. The primary problem of v20 was that the SGX module allows executable enclave pages to be created from non-executable regular pages, which could be exploited by adversaries to grant executable permissions to pages that would otherwise be denied without SGX. And that could be fixed simply by capping EPCM permissions to whatever allowed on the source page, without touching LSM. Of course the drawback is loss of functionality - i.e. self-modifying enclaves cannot be loaded unless the calling process has EXECMEM. But that should suffice, as most SGX1 applications don't contain self-modifying code anyway.

Then we could switch our focus back to LSM and work out what's relevant, especially for SGX2 and beyond.

Have a good evening.

Dr. Greg

As always,
Dr. Greg Wettstein, Ph.D, Worker
IDfusion, LLC               Implementing SGX secured and modeled
4206 N. 19th Ave.           intelligent network endpoints.
Fargo, ND  58102
PH: 701-281-1686            EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"Courage is not the absence of fear, but rather the judgement that
  something else is more important than fear."
                                 -- Ambrose Redmoon




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux