> On Apr 19, 2019, at 7:17 AM, Dr. Greg <greg@xxxxxxxxxxxx> 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?
