On Thu, Mar 05, 2020 at 11:51:57AM -0800, Sean Christopherson wrote: > On Fri, Feb 21, 2020 at 03:00:31PM +0200, Jarkko Sakkinen wrote: > > On Thu, Feb 20, 2020 at 07:19:13PM -0600, Dr. Greg wrote: > > > > > This would seem to imply that the driver is rather firmly architected > > > > > on the notion of one open() per enclave, a concept that Jethro seems > > > > > to have issues with. > > > > > > > I don't understand what concept you are talking about. > > > > > > If memory serves me correctly, Jethro envisioned a model where a > > > single open of the SGX driver node would return a file descriptor that > > > could then be used to create/load/initialize multiple enclaves. Your > > > clarifications indicate that a separate open will be needed for each > > > and every enclave instance that will be orchestrated. > > > > > > Jethro, if I'm mistating your position on this, please jump in and > > > clarify. > > > > Ah. > > > > You are speaking about having a factory to create enclaves and a > > management interface. I.e. you'd have ioctl to create enclave that gives > > you a file descriptor to access its management interface. > > > > Out of top of my head I cannot recall why this was not favored in the > > end but generally speaking added complexity should be justified by some > > considerably strong measures. > > The primary issue is that having an ioctl() to create enclaves means the > enclave fd would be an anon inode. From a security (well, SELinux) > perspective, anon inodes are problematic for two reasons: > > - Anon inodes are exempt from SELinux ioctl() whitelisting. This > probably isn't a huge deal? > > - Mapping an anon inode with PROT_EXEC requires SELinux's EXECMEM, i.e. > all enclave runtimes would require EXECMEM, which is a big step > backwards in terms of security and drew the ire of Linus[1]. > > That being said, there is a proposed patch set to add support for "secure" > anon inodes[2], which I believe would eliminate all of the above problems. > Of course we'd be stuck with the current anon inode behavior until that > patch set lands (I'm feeling optomistic today ;-) ). > > [1] https://lkml.kernel.org/r/CAHk-=wjmT=uC1=18ZYV1CMfP_FBUEjh9_rabH0g+a0z-L0cgHg@xxxxxxxxxxxxxx > [2] https://lkml.kernel.org/r/20200214032635.75434-1-dancol@xxxxxxxxxx Still does not address what I said in my response: what are the strong enough measures to use anon inode in the first place even if there is a "secure" version. /Jarkko
