Re: [PATCH v20 00/28] Intel SGX1 support

[Andy Lutomirski <luto@kernel.org>]

> On Apr 19, 2019, at 7:17 AM, Dr. Greg <greg@enjellic.com> wrote:
>
> On Thu, Apr 18, 2019 at 11:01:00AM -0700, Dave Hansen wrote:

> "The value of Intel SGX is to execute code in a protected enclave;
> however, Intel SGX does not guarantee that the code executed in the
> enclave is from a trusted source.  In all cases, we recommend
> utilizing programs, files, apps and plugins from trusted sources,"
> Intel said.

Linux *has* mechanisms to enforce the provenance of code, and they
have nothing to do with SGX.  Off the top of my head, there’s IMA,
SELinux (depending on policy), and dm-verity.

So it seems to me that our bases are already pretty well covered. I
see two cases where some additional protection for SGX might make
sense:

1. You care more about the provenance of enclaves than the provenance
of normal code.  (“You” is the platform owner, not a remote party
verifying SGX quotes.”) There are any number of solutions that could
work here, and not all of them involve crypto.

2. You care about the case where the kernel is compromised.  In this
case, nothing that's been discussed helps much on an FLC system, and
even the pre-LC systems aren't a whole lot better given the lack of
init token revocation.

But I think we may be missing a much bigger issue that does need
consideration before the driver gets merged.  We're all focusing on
*additional* SGX protections, but I'm not even sure we have the SGX
protections up to snuff with the rest of the system.  There are many,
many Linux systems that enforce a policy that *all* executable text
needs to come from a verified source.  On these systems, you can't
mmap some writable memory, write to it, and then change it to
executable.  (Obviously, JITs either don't work or need special
permissions on these systems.)

Unless I'm missing it, the current SGX API is entirely incompatible
with this model -- the host process supplies text *bytes* to the
kernel, and the kernel merrily loads those bytes into executable
enclave memory.  Whoops!

I think we may need to change the API so that enclaves are loaded from
a file where the contents of the file are in some appropriate format.
(The file should, at least, contain MRENCLAVE, but various antivirus
tools would much prefer if the actual enclave contents were in the
file.)  It's not entirely clear that the enclave text and data need to
be in the file, since they're covered by the hash.)  Then, to start an
enclave, you pass an fd to the file to the SGX driver, and the SGX
driver parses out the relevant data initializes the enclave.  Before
this happens, the driver could call into IMA and LSM hooks, and the
driver would also verify that the file didn't come from a noexec
filesystem.

I suppose another approach would be to treat SGX the same way that
ld.so is treated, mostly by requiring that the buffers passed to the
driver that contain text be marked executable.  This seems quite a bit
weakter to me.

What do you all think?