On Wed, Nov 07, 2018 at 01:40:59PM -0800, Sean Christopherson wrote: > > In that case it seems like the only way to use SGX that's not a gaping > > security hole is to run the SGX enclave in its own fully-seccomp (or > > equivalent) process, with no host application in the same address > > space. Since the host application can't see the contents of the > > enclave to make any determination of whether it's safe to run, running > > it in the same address space only makes sense if the cpu provides > > protection against unwanted accesses to the host's memory from the > > enclave -- and according to you, it doesn't. > > The enclave's code (and any initial data) isn't encrypted until the > pages are loaded into the Enclave Page Cache (EPC), which can only > be done by the kernel (via ENCLS[EADD]). In other words, both the > kernel and userspace can vet the code/data before running an enclave. > > Practically speaking, an enclave will be coupled with an untrusted > userspace runtime, i.e. it's loader. Enclaves are also measured > as part of their build process, and so the enclave loader needs to > know which pages to add to the measurement, and in what order. I > guess technically speaking an enclave could have zero pages added > to its measurement, but that'd probably be a big red flag that said > enclave is up to something fishy. IMHO the whole idea adds too much policy into kernel even if it would be doable. You can easily spawn untrusted run-time and enclave to its own process. Seccomp limits the syscall space and enclaves cannot do syscalls in the first place. It is the URT that will do them behalf of the enclave. /Jarkko
