Re: [PATCH v2 0/3] x86/sgx: eextend ioctl

[Dave Hansen]

On 4/12/21 8:58 AM, Jethro Beekman wrote:
> On 2021-04-12 17:36, Dave Hansen wrote:
>> On 4/12/21 1:59 AM, Raoul Strackx wrote:
>>> This patch set adds a new ioctl to enable userspace to execute EEXTEND
>>> leaf functions per 256 bytes of enclave memory. With this patch in place,
>>> Linux will be able to build all valid SGXv1 enclaves.
>> This didn't cover why we need a *NEW* ABI for this instead of relaxing
>> the page alignment rules in the existing one.
>>
> In executing the ECREATE, EADD, EEXTEND, EINIT sequence, you currently have 2 options for EADD/EEXTEND using the SGX_IOC_ENCLAVE_ADD_PAGES ioctl:
> - execute EADD on any address
> - execute EADD on any address followed by 16× EEXTEND for that address span

I think you forgot a key piece of the explanation here.  The choice as
to whether you just EADD or EADD+16xEEXTEND is governed by the addition
of the: SGX_PAGE_MEASURE flag.

> Could you be more specific on how you're suggesting that the current ioctl is modified to in addition support the following?
> - execute EEXTEND on any address

I'm still not convinced you *NEED* EEXTEND on arbitrary addresses.

Right now, we have (roughly):

	 ioctl(ADD_PAGES, ptr, PAGE_SIZE, MEASURE)

which translates in the kernel to:

	__eadd(ptr, epc)
	if (flags & MEASURE) {
		for (i = 0; i < PAGE_SIZE/256; i++)
			__eextend(epc + i*256);
	}

Instead, we could allow add_arg.src and add_arg.offset to be
non-page-aligned.  Then, we still do the same __eadd(), but modify the
__eextend() loop to only cover the actual range referred to by 'add_arg'.

The downside is that you only get a single range of measured data per
page.  Let's say a 'X' means measured (EEXTEND'ed) and '_' means not.
You could have patterns like:

	XXXXXXXXXXXXXXXX
or
	XXXXXXXXXXXXXXX_
or
	____XXXXXXXXXXXX

but not:

	_X_X_X_X_X_X_X_X
or
	_XXXXXXXXXXXXXX_


Is that a problem?