Re: x86/sgx: v23-rc2

From: Jethro Beekman <jethro@fortanix.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: "Dr. Greg" <greg@enjellic.com>, Andy Lutomirski <luto@kernel.org>,
	"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
	"serge.ayoun@intel.com" <serge.ayoun@intel.com>,
	"shay.katz-zamir@intel.com" <shay.katz-zamir@intel.com>
Subject: Re: x86/sgx: v23-rc2
Date: Thu, 5 Mar 2020 21:34:01 +0100	[thread overview]
Message-ID: <1bd3295e-02b3-ac5c-8545-0bb8cbd4cf48@fortanix.com> (raw)
In-Reply-To: <20200305195157.GO11500@linux.intel.com>

[-- Attachment #1: Type: text/plain, Size: 2336 bytes --]

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).

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

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4054 bytes --]