Re: [PATCH 2/4] x86/sgx: Put enclaves into anonymous files

From: Topi Miettinen <toiwoton@gmail.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	Jethro Beekman <jethro@fortanix.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Andy Lutomirski <luto@kernel.org>,
	casey.schaufler@intel.com,
	Sean Christopherson <sean.j.christopherson@intel.com>,
	linux-sgx@vger.kernel.org, "Svahn, Kai" <kai.svahn@intel.com>,
	"Schlobohm, Bruce" <bruce.schlobohm@intel.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Haitao Huang <haitao.huang@linux.intel.com>,
	ben@decadent.org.uk
Subject: Re: [PATCH 2/4] x86/sgx: Put enclaves into anonymous files
Date: Thu, 9 Apr 2020 00:15:36 +0300	[thread overview]
Message-ID: <64ee4f81-0169-e4f1-9bfb-1b369ee917c4@gmail.com> (raw)
In-Reply-To: <20200408134049.GB4097@linux.intel.com>

On 8.4.2020 16.40, Jarkko Sakkinen wrote:
> On Tue, Apr 07, 2020 at 10:54:46PM +0300, Topi Miettinen wrote:
>> On 7.4.2020 21.04, Jarkko Sakkinen wrote:
>>> On Tue, Apr 07, 2020 at 07:59:00PM +0300, Jarkko Sakkinen wrote:
>>>> On Tue, Apr 07, 2020 at 07:57:08PM +0300, Jarkko Sakkinen wrote:
>>>>> On Tue, Apr 07, 2020 at 12:04:58PM +0300, Topi Miettinen wrote:
>>>>>> Please correct me if I'm wrong, but isn't it the goal of SGX to let a
>>>>>> (suitably privileged) process designate some of its memory areas as part of
>>>>>> SGX enclave? If so, why don't you simply add a system call to do so, such as
>>>>>>
>>>>>> int sgx_mprotect(void *start, size_t length, int prot, u64 sgx_flags);
>>>>>>
>>>>>> like existing pkey_mprotect()? Or add a flag PROT_SGX to mprotect() like
>>>>>> existing PROT_SAO/PROT_SEM?
>>>>>>
>>>>>> -Topi
>>>>>
>>>>> New syscalls is always the last resort path, especially if they are
>>>>> associated with an arch.
>>>>>
>>>>> PROT_SGX sounds something worth of consideration.
>>>>>
>>>>> Another idea to throw would be noexec_dev mount option that would allow
>>>>> exec *only* for the device nodes (zero analysis done on feasibility).
>>>>
>>>> The 2nd proposal has the merit that it would scale above SGX and
>>>> does not give additional strengths to the adversary in the context
>>>> of the threat scenario.
>>>
>>> Or.
>>>
>>> Why couldn't kernel just disallow anything but device files to be
>>> created to devtmpfs unconditionally?
>>
>> It seems to be just a regular tmpfs but with direct access to add device
>> nodes when drivers are loaded. Nice idea, maybe something like that could be
>> done with SELinux policy.
> 
> Anyway, thank you for all the feedback.
> 
> What starts to be obvious is that we don't do anything in code level
> in SGX particular but instead workaround something around /dev.

If you take the /dev/sgx path, perhaps you could use KVM as a reference. 
It uses a similar special device /dev/kvm, works well with noexec /dev 
but still it can be used to do much more complex stuff than SGX.

-Topi