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

[Jethro Beekman <jethro@fortanix.com>]

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

On 2021-04-02 20:42, Dave Hansen wrote:
> On 4/2/21 11:31 AM, Jethro Beekman wrote:
>> On 2021-04-02 17:53, Dave Hansen wrote:
>>> On 4/2/21 1:38 AM, Jethro Beekman wrote:
>>>>> So, we're talking here about pages that have been EEADDED, but for
>>>>> which we do not want to include the entire contents of the page?
>>>>> Do these contents always include the beginning of the page, or can
>>>>> the holes be anywhere?
>>>> Holes can be anywhere, and EEXTEND calls need not be sequential in
>>>> memory address or even relate to the most recently EADDed page.
>>>
>>> I think you're referring to the SGX architecture itself here.  The
>>> architecture permits this, right?
>>
>> Yes.
>>
>>> But, why would an enclave loader application ever do this? 
>>
>> e.g. to save space
> 
> How does this save space, exactly?  What space does it save?

With the current driver interface, if you want to communicate an application binary that has pages that are at least partially measured, you need to communicate the entire page (to ensure the same measurement for the entire page), even though most of that page's contents are irrelevant to the application.

> 
> Let's say I want to add 4352 bytes of data to an enclave.  Today, I have
> to page-align the beginning and end of that 4352 bytes, and call the add
> ioctl() to add the two resulting pages.  It consumes two EPC pages.
> 
> With EEXTEND, if I want to add the data, I only need to page-align the
> beginning of the data.  I call add_page on the first page, then eextend
> on the 256 bytes.  It consumes two EPC pages.
> 
> I guess you can argue that this saves padding out the second page, which
> would *theoretically* temporarily eat up one extra page of non-enclave
> memory and the cost of a 256-byte memcpy.
> 
>>> Is this something we want to support in Linux?
>>
>> Why not? Is there a good reason to not fully support this part of the
>> CPU architecture?
> 
> We don't blindly support CPU features in Linux.  They need to do
> something *useful*.  I'm still missing what this does which is useful.

Enclaves can only be loaded exactly as specified by the developer, this is the whole point of the measurement architecture. By not supporting arbitrary EADD/EEXTEND flows, the SGX application ecosystem is effectively split into two: SGX applications that run everywhere and SGX applications that run everywhere except on Linux. So, the "something useful" is being compatible. Linux has plenty of features that exist solely for compatibility with other systems, such as binfmt_misc.

> 
> Does any actual, real-world enclave want this functionality?  Why?
> 
> P.S. There are plenty of things you can do with the SGX architecture
> that we probably won't ever implement in Linux.
> 

How so? Linux doesn't normally put arbitrary restrictions on what userspace does when it's not interacting with the kernel. Userspace is free to load its own memory contents and execute all the instructions it wants. AFAIK, besides this EEXTEND issue there is nothing of the SGX architecture that SGX applications may be using that's not supported.

--
Jethro Beekman | Fortanix


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