[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <da7ae1e7-59b8-63db-a9f1-607b4e529639@fortanix.com>
Date: Mon, 12 Apr 2021 10:59:56 +0200
From: Raoul Strackx <raoul.strackx@...tanix.com>
To: 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: [PATCH v2 0/3] x86/sgx: eextend ioctl
Creation of an SGX enclave consists of three steps. First, a new enclave
environment is created by the ECREATE leaf function. Some enclave settings
are specified at this step by passing an SGX Enclave Control Structure
(SECS) that contains the enclave MRENCLAVE, MRSIGNER, etc. This
instruction also starts a cryptographic log of the enclave being built.
(This log should eventually result in the MRENCLAVE.) Second, pages are
added to the enclave. The EADD leaf function copies 4KB data to an empty
EPC page. The cryptographic log records (among other properties) the
location and access rights of the page being added. It _does not_ include
an entry of the page content. When the enclave writer wishes to ensure the
content of (a part of) the enclave page as well, she must use the EEXTEND
leaf function. Extending the enclave cryptographic log can only be done
per 256 bytes. Extending the log with a full 4K page thus requires 16
invocations of the EEXTEND leaf function. It is however up to the enclave
developer to decide if and how enclave memory is added to the
cryptographic log. EEXTEND functions may be issued only for relevant parts
of an enclave page, may happen only after all pages have been added, and
so on. Finally, the enclave is finalized by the EINIT leaf function. Any
new invocations of the EADD or EEXTEND leaf functions will result in a
fault. With EINIT a number of checks are performed as well. The
cryptographic hash of the final cryptographic log is compared to the
MRENCLAVE field of the SECS structure passed to the ECREATE leaf function
(see step one). The signature (MRSIGNER) over this MRENCLAVE is verified
as well. When all checks pass, the enclave loading is complete and it
enters the executable state.
The SGX driver currently only supports extending the cryptographic log as
part of the EADD leaf function and _must_ cover complete 4K pages.
Enclaves not constructed within these constraints, currently cannot be
loaded on the Linux platform. Trying to do so will result in a different
cryptographic log; the MRENCLAVE specified at enclave creation time will
not match the cryptographic log kept by the processor and EINIT will fail.
This poses practical problems:
- The current driver does not fully support all possible SGXv1 enclaves.
It creates a separation between enclaves that run everywhere and
enclaves that run everywhere, except on Linux. This includes enclaves
already in use on other systems today.
- It limits optimizations loaders are able to perform. For example, by
only measuring relevant parts of enclave pages, load time can be
minimized.
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.
See additional discussion at:
https://lore.kernel.org/linux-sgx/20200220221038.GA26618@linux.intel.com/
T/#m93597f53d354201e72e26d93a968f167fcdf5930
Raoul Strackx (3):
x86/sgx: Adding eextend ioctl
x86/sgx: Fix compatibility issue with OPENSSL < 1.1.0
x86/sgx: eextend ioctl selftest
arch/x86/include/uapi/asm/sgx.h | 11 +++++
arch/x86/kernel/cpu/sgx/ioctl.c | 81 ++++++++++++++++++++++++++++-----
tools/testing/selftests/sgx/defines.h | 1 +
tools/testing/selftests/sgx/load.c | 57 +++++++++++++++++++----
tools/testing/selftests/sgx/main.h | 1 +
tools/testing/selftests/sgx/sigstruct.c | 43 ++++++++---------
6 files changed, 154 insertions(+), 40 deletions(-)
--
2.7.4
Powered by blists - more mailing lists