linux-kernel - Re: [PATCH RFC] x86: Add SGX_IOC_ENCLAVE_AUGMENT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <op.1il7jxj8wjvjmi@hhuan26-mobl1.mshome.net>
Date:   Sun, 06 Mar 2022 09:20:11 -0600
From:   "Haitao Huang" <haitao.huang@...ux.intel.com>
To:     linux-sgx@...r.kernel.org, "Jarkko Sakkinen" <jarkko@...nel.org>
Cc:     "Reinette Chatre" <reinette.chatre@...el.com>,
        "Nathaniel McCallum" <nathaniel@...fian.com>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        "Thomas Gleixner" <tglx@...utronix.de>,
        "Ingo Molnar" <mingo@...hat.com>, "Borislav Petkov" <bp@...en8.de>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFC] x86: Add SGX_IOC_ENCLAVE_AUGMENT_PAGES

On Fri, 04 Mar 2022 07:50:43 -0600, Jarkko Sakkinen <jarkko@...nel.org>  
wrote:

> On Fri, 2022-03-04 at 14:28 +0200, Jarkko Sakkinen wrote:
>> With SGX1 an enclave needs to be created with its maximum memory demands
>> allocated. Pages cannot be added to an enclave after it is initialized.
>> SGX2 introduces a new function, ENCLS[EAUG], that can be used to add  
>> pages
>> to an initialized enclave. With SGX2 the enclave still needs to set  
>> aside
>> address space for its maximum memory demands during enclave creation,  
>> but
>> all pages need not be added before enclave initialization. Pages can be
>> added during enclave runtime.
>>
>> Add support for dynamically adding pages to an initialized enclave with
>> SGX_IOC_ENCLAVE_AUGMENT_PAGES, which performs EAUG's to a given range of
>> pages. Do not enforce any particular permissions from kernel, like is  
>> done
>> for the pages added during the pre-initialization phase, as enclave
>> controls the final permissions and content for these pages by issuing
>> either ENCLU[EACCEPT] (empty RW) or ENCLU[EACCEPTCOPY] (arbitrary data  
>> and
>> permissions).
>>
>> Explicit EAUG ioctl is a better choice than an implicit EAUG from a page
>> fault handler because it allows to have O(1) number of kernel-enclave  
>> round
>> trips for EAUG-EACCEPT{COPY} process, instead of O(n), as it is in the  
>> case
>> when a page fault handler EAUG single page at a time.
>>
>> Cc: Reinette Chatre <reinette.chatre@...el.com>
>> Cc: Nathaniel McCallum <nathaniel@...fian.com>
>> Signed-off-by: Jarkko Sakkinen <jarkko@...nel.org>
>> ---
>> Is contained in sgx2-v2.1 branch of  
>> git://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git
>
> I created sgx2-v2.2 branch, which has #PF EAUG removed. I
> also moved selftests to the tail in the patch sets so that
> it is easier to update them reflecting these and future
> changes. Having them intervened makes things just complicated.
>
> I focus now to implement mmap() for Enarx with this, so no
> kselftest update just yet.
>
> Roughly the sequence in Enarx is:
>
> 1. Enclave traps on syscall (opcode).
> 2. Host jumps to shim expection handler.
> 3. Enclave copies the mmap() arguments to a buffer outside
>    the enclave.
> 4. Enclave exists back to the host.
> 5. Host performs EAUG to the mmap range.
> 6. Host performs mmap() to the mmap range, which succeeds
>    given that vm_max_prot_bits is RWX (i.e. disabled for
>    dynamic pages).
> 7. Host jumps back to the enclave and execution continues
>    there in the mmap handler.
> 8. mmap handler does a series of EACCEPTCOPY operations for
>    the range with given permissions and empty page as the
>    input data.
>
EACCEPTCOPY will require target pages with RW in PTE. So you would need to  
make mprotect to change PTE permissions afterwards depending on your  
target permissions.

Without knowing much your context, if your intent is to  
EACCEPTCOPY(EPCM.RX/EPCM.R, EPCM.pending), then I don't see how the page  
can be used later without making it RW again first, and copy real data  
into it.
So these empty EACCEPTCOPYs may be better just EACCEPTs(EPCM.RW,  
EPCM.pending). Then after copy real data into the pages, you do  
EMODPE/EMODPR as needed.


EACCEPTCOPY would make more sense when you already have data to be copied  
into the EAUG'd but pending EPC pages.

> Some details might differ a bit but this gives the basic idea.
> I like the fact the roud-trips are kind of in control and not
> variable, and it is pretty easy to use to implement the basic
> syscall behaviour. This has of course some corner cases but
> my sequence describes the main flow anyway.
>
> Take it or leave it but this does give at least for me a sound
> way to implement my workload. I'll use this up until my changes
> have been inducted to the original patch set, or it starts to
> look sane with other solutions. The original patch set simply
> does not work for us at all.
>
> BR, Jarkko