[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <247ffbee-0ef6-1b6f-75aa-2dc06df42d5d@intel.com>
Date: Thu, 1 Apr 2021 11:40:04 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Raoul Strackx <raoul.strackx@...tanix.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
linux-sgx@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 0/3] x86/sgx: eextend ioctl
On 4/1/21 10:49 AM, Raoul Strackx wrote:
> On 4/1/21 6:11 PM, Dave Hansen wrote:
>> On 4/1/21 7:56 AM, Raoul Strackx wrote:
>>> SOLUTION OF THIS PATCH
>>> This patch adds a new ioctl to enable userspace to execute EEXTEND leaf
>>> functions per 256 bytes of enclave memory. This enables enclaves to be
>>> build as specified by enclave providers.
>> I think tying the user ABI to the SGX architecture this closely is a
>> mistake.
>>
>> Do we need another ioctl() or can we just relax the existing add_pages
>> ioctl() to allow unaligned addresses?
>>
> I've considered this. In order to do an EEXTEND without an EADD, we'd
> need to add a flag DONT_ADD_PAGES flag to `add_pages` ioctl as well. Two
> separate ioctls, one for adding, another for extending made more sense
> to me.
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?
Powered by blists - more mailing lists