On 2019-07-08 10:29, Sean Christopherson wrote:
On Fri, Jul 05, 2019 at 07:05:49PM +0300, Jarkko Sakkinen wrote:On Wed, Jun 19, 2019 at 03:23:49PM -0700, Sean Christopherson wrote: I still don't get why we need this whole mess and do not simply admit that there are two distinct roles: 1. Creator 2. UserBecause SELinux has existing concepts of EXECMEM and EXECMOD.In the SELinux context Creator needs FILE__WRITE and FILE__EXECUTE but User does not. It just gets the fd from the Creator. I'm sure that all the SGX2 related functionality can be solved somehow in this role playing game. An example would be the usual case where enclave is actually a loader that loads the actual piece of software that one wants to run. Things simply need to be designed in a way the Creator runs the loader part. These are non-trivial problems but oddball security model is not going to make them disappear - on the contrary it will make designing user space only more complicated. I think this is classical example of when something overly complicated is invented in the kernel only to realize that it should be solved in the user space. It would not be like the only use case where some kind of privileged daemon is used for managing some a kernel provided resource. I think a really good conclusion from this discussion that has taken two months is to realize that nothing needs to be done in this area (except *maybe* noexec check).Hmm, IMO we need to support at least equivalents to EXECMEM and EXECMOD. 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.
Why do you need to add reserved fields now? Isn't this what incorporating the struct size in the ioctl number is for?
-- Jethro Beekman | Fortanix
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
