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?
