Re: x86/sgx: v23-rc2

[Sean Christopherson <sean.j.christopherson@intel.com>]

On Thu, Mar 05, 2020 at 09:34:01PM +0100, Jethro Beekman wrote:
> On 2020-03-05 20:51, 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.
> 
> Why would it have to be an anon inode? Can't it just be the same inode as the
> device file? As I mentioned it just needs to be a different struct file
> (since that's what actually owns the enclave). I'm envisioning you still need
> to open the device first (once).

Hmm, poking around, alloc_file_clone() looks like it would do the trick.
But we are waaaaay outside my area of expertise, I'll let Andy or someone
else weigh in on whether or not this is sane.

> Yes, a UDS with SCM_RIGHTS could work, this is similar from a capability
> model perspective. It does make things a lot more complicated if you want to
> employ userspace security techniques. For example, when using seccomp a
> common use is to avoid the creation of arbitrary fds. It's rather hard to
> write a good set of rules for recvmsg with SCM_RIGHTS since the fds are
> passed from outside. Whitelisting a single ioctl is much easier. Also, you'd
> need to create a whole separate process whose job it is to hand out these
> enclave fds. That process still needs to be privileged and would probably
> need its own set of seccomp rules.
> 
> -- Jethro Beekman | Fortanix
>