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: <13e0c364328ed822c5d358416bb13aa5faea3195.camel@kernel.org>
Date:   Fri, 04 Mar 2022 15:50:43 +0200
From:   Jarkko Sakkinen <jarkko@...nel.org>
To:     linux-sgx@...r.kernel.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, 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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ