On Fri, Jun 16, 2017 at 9:31 AM, Christopherson, Sean J <sean.j.christopherson@xxxxxxxxx> wrote: > I think there is a certain amount of inception going on here, i.e. the only > reason we're discussing LE enforced policies in the kernel is because the LE > architecture exists and can't be disabled. The LE, as originally designed, > is intended to be a way for *userspace* to control what code can run on the > system, e.g. to provide a hook for anti-virus/malware to inspect an enclave > since it's impossible to inspect an enclave once it is running. > > The kernel doesn't need an LE to restrict what enclaves can run, e.g. it can > perform inspection at any point during the initialization process. This is > true for guest enclaves as well since the kernel can trap EINIT. By making > the LE kernel-only we've bastardized the concept of the LE and have negated > the primary value provided by an LE[1][2]. In my opinion, the discussion of > the kernel's launch policies is much ado about nothing, e.g. if supported by > hardware, I think we'd opt to disable launch control completely. Agreed. I don't think I've ever said that the kernel should implement restrictions on what enclaves should run [1]. All I've said is that (a) if the kernel does implement restrictions like this, it should apply them to guests as well and (b) that the kernel should probably trap EINIT because that's the most sensible way to deal with the MSRs. [1] With the possible exception of provisioning enclaves. I'm still not convinced that anyone except root should be allowed to run an exclave with the provision bit set, as that bit gives access to the provisioning key, which is rather special. From memory, it bypasses the owner epoch, and it may have privacy issues. Maybe this is a nonissue, but I'd like to see someone seriously analyze how provisioning enclaves that may not be signed by Intel affect the overall security of the system and how Linux should handle them. SGX was designed under the assumption that provisioning enclaves would only ever be signed by Intel, and that's not the case any more, and dealing with this intelligently may require some thought.
