diff mbox series

[v14,19/19] x86/sgx: Driver documentation

Message ID 20180925130845.9962-20-jarkko.sakkinen@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series Intel SGX1 support | expand

Commit Message

Jarkko Sakkinen Sept. 25, 2018, 1:06 p.m. UTC 
Documentation of the features of the Software Guard eXtensions used
by the Linux kernel and basic design choices for the core and driver
and functionality.

Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 Documentation/index.rst         |   1 +
 Documentation/x86/intel_sgx.rst | 185 ++++++++++++++++++++++++++++++++
 2 files changed, 186 insertions(+)
 create mode 100644 Documentation/x86/intel_sgx.rst

Comments

Jonathan Corbet Sept. 25, 2018, 1:27 p.m. UTC | #1 
On Tue, 25 Sep 2018 16:06:56 +0300
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:

> Documentation of the features of the Software Guard eXtensions used
> by the Linux kernel and basic design choices for the core and driver
> and functionality.
> 
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  Documentation/index.rst         |   1 +
>  Documentation/x86/intel_sgx.rst | 185 ++++++++++++++++++++++++++++++++
>  2 files changed, 186 insertions(+)
>  create mode 100644 Documentation/x86/intel_sgx.rst
> 
> diff --git a/Documentation/index.rst b/Documentation/index.rst
> index 5db7e87c7cb1..1cdc139adb40 100644
> --- a/Documentation/index.rst
> +++ b/Documentation/index.rst
> @@ -104,6 +104,7 @@ implementation.
>     :maxdepth: 2
>  
>     sh/index
> +   x86/index

So you're adding this reference to x86/index, but the actual file
(Documentation/x86/index.rst) doesn't exist; that will break the docs
build.  I do appreciate your doing your document in RST, though!

Who is the intended audience for this document?  I see a bit of UAPI
stuff that might be better placed in the userspace-api manual, mixed with
stuff that user-space developers are unlikely to take much interest in.
Might it be worth splitting this into two pieces?

Thanks,

jon
Pavel Machek Oct. 15, 2018, 8:54 p.m. UTC | #2 
On Tue 2018-09-25 16:06:56, Jarkko Sakkinen wrote:
> Documentation of the features of the Software Guard eXtensions used
> by the Linux kernel and basic design choices for the core and driver
> and functionality.
> 
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

> --- /dev/null
> +++ b/Documentation/x86/intel_sgx.rst
> @@ -0,0 +1,185 @@
> +===================
> +Intel(R) SGX driver
> +===================
> +
> +Introduction
> +============
> +
> +Intel(R) SGX is a set of CPU instructions that can be used by applications to
> +set aside private regions of code and data. The code outside the enclave is
> +disallowed to access the memory inside the enclave by the CPU access control.
> +In a way you can think that SGX provides inverted sandbox. It protects the
> +application from a malicious host.

Well, recently hardware had some problems keeping its
promises. So... what about rowhammer, meltdown and spectre?

Which ones apply, which ones do not, and on what cpu generations?

> +Overview of SGX
> +===============
> +
> +SGX has a set of data structures to maintain information about the enclaves and
> +their security properties. BIOS reserves a fixed size region of physical memory
> +for these structures by setting Processor Reserved Memory Range Registers
> +(PRMRR).
> +
> +This memory range is protected from outside access by the CPU and all the data
> +coming in and out of the CPU package is encrypted by a key that is generated for
> +each boot cycle.

Encryption, that sounds nice, but it is hard to do right. If SGX
protected code changes single bit in its memory, how many bits will be
changed in physical RAM?

Can we get security people to look at this and perhaps tells us what
properties it has?

Thanks,
									Pavel
Jarkko Sakkinen Oct. 17, 2018, 11:45 p.m. UTC | #3 
On Mon, 15 Oct 2018, Pavel Machek wrote:
> On Tue 2018-09-25 16:06:56, Jarkko Sakkinen wrote:
>> +Intel(R) SGX is a set of CPU instructions that can be used by applications to
>> +set aside private regions of code and data. The code outside the enclave is
>> +disallowed to access the memory inside the enclave by the CPU access control.
>> +In a way you can think that SGX provides inverted sandbox. It protects the
>> +application from a malicious host.
>
> Well, recently hardware had some problems keeping its
> promises. So... what about rowhammer, meltdown and spectre?

Doesn't hardware always have this problem over time?

> Which ones apply, which ones do not, and on what cpu generations?

Definitely should be refined.

Meltdowns approach AFAIK does not work because reads outside the enclave
will always have a predefined value (-1) but only if the page is present,
which was later exploited in the Foreshadow attack.

> Encryption, that sounds nice, but it is hard to do right. If SGX
> protected code changes single bit in its memory, how many bits will be
> changed in physical RAM?

512-bit blocks and merkle tree based mac. It is pretty well documented
in https://eprint.iacr.org/2016/204.pdf. I'll take not to myself to add
this to the references.

Thanks for the feedback. The ocumentation is hard to drive forward w/o it.

/Jarkko
Dave Hansen Oct. 17, 2018, 11:56 p.m. UTC | #4 
On 10/15/2018 01:54 PM, Pavel Machek wrote:
>> +Intel(R) SGX is a set of CPU instructions that can be used by applications to
>> +set aside private regions of code and data. The code outside the enclave is
>> +disallowed to access the memory inside the enclave by the CPU access control.
>> +In a way you can think that SGX provides inverted sandbox. It protects the
>> +application from a malicious host.
> Well, recently hardware had some problems keeping its
> promises. So... what about rowhammer, meltdown and spectre?

There's a ton of documentation out there about what kinds of protections
SGX provides.  I don't think this is an appropriate place to have an
exhaustive discussion about it.  But, there's extensive discussion of it
on Intel's security site:

https://software.intel.com/security-software-guidance/

There's documentation on how L1TF affects SGX here:

https://software.intel.com/security-software-guidance/software-guidance/l1-terminal-fault

Or Spectre v2 here:

https://software.intel.com/security-software-guidance/software-guidance/bounds-check-bypass

> Which ones apply, which ones do not, and on what cpu generations?

The CVEs list this in pretty exhaustive detail.  The L1TF/SGX one, for
example:

https://nvd.nist.gov/vuln/detail/CVE-2018-3615

Lists a bunch of processor models.
Pavel Machek Oct. 18, 2018, 9:57 a.m. UTC | #5 
On Thu 2018-10-18 02:45:27, Jarkko Sakkinen wrote:
> On Mon, 15 Oct 2018, Pavel Machek wrote:
> >On Tue 2018-09-25 16:06:56, Jarkko Sakkinen wrote:
> >>+Intel(R) SGX is a set of CPU instructions that can be used by applications to
> >>+set aside private regions of code and data. The code outside the enclave is
> >>+disallowed to access the memory inside the enclave by the CPU access control.
> >>+In a way you can think that SGX provides inverted sandbox. It protects the
> >>+application from a malicious host.
> >
> >Well, recently hardware had some problems keeping its
> >promises. So... what about rowhammer, meltdown and spectre?
> 
> Doesn't hardware always have this problem over time?

No, not really.

In this case, tries to protect from hardware "attacks" done by machine
owner. That job is theoretically impossible, so you have harder
situation than most..

> >Which ones apply, which ones do not, and on what cpu generations?
> 
> Definitely should be refined.
> 
> Meltdowns approach AFAIK does not work because reads outside the enclave
> will always have a predefined value (-1) but only if the page is present,
> which was later exploited in the Foreshadow attack.

What about L1tf and https://github.com/lsds/spectre-attack-sgx ?

									Pavel
Jarkko Sakkinen Oct. 19, 2018, 11:59 p.m. UTC | #6 
On Thu, 18 Oct 2018, Pavel Machek wrote:
>> Definitely should be refined.
>>
>> Meltdowns approach AFAIK does not work because reads outside the enclave
>> will always have a predefined value (-1) but only if the page is present,
>> which was later exploited in the Foreshadow attack.
>
> What about L1tf and https://github.com/lsds/spectre-attack-sgx ?

L1TF is the vuln and Foreshadow is the attack taking advantage of the
vuln. I didn't mean to patch the documention in my response or give
extensive list of the vulns if you expected that.

For kernel documentation it does make sense to give a threat model
but not enumerate every possible vuln.

/Jarkko
diff mbox series

Patch

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 5db7e87c7cb1..1cdc139adb40 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -104,6 +104,7 @@  implementation.
    :maxdepth: 2
 
    sh/index
+   x86/index
 
 Filesystem Documentation
 ------------------------
diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst
new file mode 100644
index 000000000000..f6b7979c41f2
--- /dev/null
+++ b/Documentation/x86/intel_sgx.rst
@@ -0,0 +1,185 @@ 
+===================
+Intel(R) SGX driver
+===================
+
+Introduction
+============
+
+Intel(R) SGX is a set of CPU instructions that can be used by applications to
+set aside private regions of code and data. The code outside the enclave is
+disallowed to access the memory inside the enclave by the CPU access control.
+In a way you can think that SGX provides inverted sandbox. It protects the
+application from a malicious host.
+
+You can tell if your CPU supports SGX by looking into ``/proc/cpuinfo``:
+
+	``cat /proc/cpuinfo  | grep sgx``
+
+Overview of SGX
+===============
+
+SGX has a set of data structures to maintain information about the enclaves and
+their security properties. BIOS reserves a fixed size region of physical memory
+for these structures by setting Processor Reserved Memory Range Registers
+(PRMRR).
+
+This memory range is protected from outside access by the CPU and all the data
+coming in and out of the CPU package is encrypted by a key that is generated for
+each boot cycle.
+
+Enclaves execute in ring-3 in a special enclave submode using pages from the
+reserved memory range. A fixed logical address range for the enclave is reserved
+by ENCLS(ECREATE), a leaf instruction used to create enclaves. It is referred in
+the documentation commonly as the ELRANGE.
+
+Every memory access to the ELRANGE is asserted by the CPU. If the CPU is not
+executing in the enclave mode inside the enclave, #GP is raised. On the other
+hand enclave code can make memory accesses both inside and outside of the
+ELRANGE.
+
+Enclave can only execute code inside the ELRANGE. Instructions that may cause
+VMEXIT, IO instructions and instructions that require a privilege change are
+prohibited inside the enclave. Interrupts and exceptions always cause enclave
+to exit and jump to an address outside the enclave given when the enclave is
+entered by using the leaf instruction ENCLS(EENTER).
+
+Data types
+----------
+
+The protected memory range contains the following data:
+
+* **Enclave Page Cache (EPC):** protected pages
+* **Enclave Page Cache Map (EPCM):** a database that describes the state of the
+  pages and link them to an enclave.
+
+EPC has a number of different types of pages:
+
+* **SGX Enclave Control Structure (SECS)**: describes the global
+  properties of an enclave.
+* **Regular (REG):** code and data pages in the ELRANGE.
+* **Thread Control Structure (TCS):** pages that define entry points inside an
+  enclave. The enclave can only be entered through these entry points and each
+  can host a single hardware thread at a time.
+* **Version Array (VA)**: 64-bit version numbers for pages that have been
+  swapped outside the enclave. Each page contains 512 version numbers.
+
+Launch control
+--------------
+
+To launch an enclave, two structures must be provided for ENCLS(EINIT):
+
+1. **SIGSTRUCT:** signed measurement of the enclave binary.
+2. **EINITTOKEN:** a cryptographic token CMAC-signed with a AES256-key called
+   *launch key*, which is re-generated for each boot cycle.
+
+The CPU holds a SHA256 hash of a 3072-bit RSA public key inside
+IA32_SGXLEPUBKEYHASHn MSRs. Enclaves with a SIGSTRUCT that is signed with this
+key do not require a valid EINITTOKEN and can be authorized with special
+privileges. One of those privileges is ability to acquire the launch key with
+ENCLS(EGETKEY).
+
+**IA32_FEATURE_CONTROL[17]** is used by the BIOS configure whether
+IA32_SGXLEPUBKEYHASH MSRs are read-only or read-write before locking the
+feature control register and handing over control to the operating system.
+
+Enclave construction
+--------------------
+
+The construction is started by filling out the SECS that contains enclave
+address range, privileged attributes and measurement of TCS and REG pages (pages
+that will be mapped to the address range) among the other things. This structure
+is passed out to the ENCLS(ECREATE) together with a physical address of a page
+in EPC that will hold the SECS.
+
+The pages are added with ENCLS(EADD) and measured with ENCLS(EEXTEND) i.e.
+SHA256 hash MRENCLAVE residing in the SECS is extended with the page data.
+
+After all of the pages have been added, the enclave is initialized with
+ENCLS(EINIT). ENCLS(INIT) checks that the SIGSTRUCT is signed with the contained
+public key. If the given EINITTOKEN has the valid bit set, the CPU checks that
+the token is valid (CMAC'd with the launch key). If the token is not valid,
+the CPU will check whether the enclave is signed with a key matching to the
+IA32_SGXLEPUBKEYHASHn MSRs.
+
+Swapping pages
+--------------
+
+Enclave pages can be swapped out with ENCLS(EWB) to the unprotected memory. In
+addition to the EPC page, ENCLS(EWB) takes in a VA page and address for PCMD
+structure (Page Crypto MetaData) as input. The VA page will seal a version
+number for the page. PCMD is 128 byte structure that contains tracking
+information for the page, most importantly its MAC. With these structures the
+enclave is sealed and rollback protected while it resides in the unprotected
+memory.
+
+Before the page can be swapped out it must not have any active TLB references.
+ENCLS(EBLOCK) instruction moves a page to the *blocked* state, which means
+that no new TLB entries can be created to it by the hardware threads.
+
+After this a shootdown sequence is started with ENCLS(ETRACK), which sets an
+increased counter value to the entering hardware threads. ENCLS(EWB) will
+return SGX_NOT_TRACKED error while there are still threads with the earlier
+couner value because that means that there might be hardware thread inside
+the enclave with TLB entries to pages that are to be swapped.
+
+Kernel internals
+================
+
+Requirements
+------------
+
+Because SGX has an ever evolving and expanding feature set, it's possible for
+a BIOS or VMM to configure a system in such a way that not all CPUs are equal,
+e.g. where Launch Control is only enabled on a subset of CPUs.  Linux does
+*not* support such a heterogeneous system configuration, nor does it even
+attempt to play nice in the face of a misconfigured system.  With the exception
+of Launch Control's hash MSRs, which can vary per CPU, Linux assumes that all
+CPUs have a configuration that is identical to the boot CPU.
+
+
+Roles and responsibilities
+--------------------------
+
+SGX introduces system resources, e.g. EPC memory, that must be accessible to
+multiple entities, e.g. the native kernel driver (to expose SGX to userspace)
+and KVM (to expose SGX to VMs), ideally without introducing any dependencies
+between each SGX entity.  To that end, the kernel owns and manages the shared
+system resources, i.e. the EPC and Launch Control MSRs, and defines functions
+that provide appropriate access to the shared resources.  SGX support for
+user space and VMs is left to the SGX platform driver and KVM respectively.
+
+Launching enclaves
+------------------
+
+The current kernel implementation supports only unlocked MSRs i.e.
+FEATURE_CONTROL_SGX_LE_WR must be set. The launch is performed by setting the
+MSRs to the hash of the public key modulus of the enclave signer, which is one
+f the fields in the SIGSTRUCT.
+
+EPC management
+--------------
+
+Due to the unique requirements for swapping EPC pages, and because EPC pages
+(currently) do not have associated page structures, management of the EPC is
+not handled by the standard Linux swapper.  SGX directly handles swapping
+of EPC pages, including a kthread to initiate reclaim and a rudimentary LRU
+mechanism. The consumers of EPC pages, e.g. the SGX driver, are required to
+implement function callbacks that can be invoked by the kernel to age,
+swap, and/or forcefully reclaim a target EPC page.  In effect, the kernel
+controls what happens and when, while the consumers (driver, KVM, etc..) do
+the actual work.
+
+SGX uapi
+========
+
+.. kernel-doc:: drivers/platform/x86/intel_sgx/sgx_ioctl.c
+   :functions: sgx_ioc_enclave_create
+               sgx_ioc_enclave_add_page
+               sgx_ioc_enclave_init
+
+.. kernel-doc:: arch/x86/include/uapi/asm/sgx.h
+
+References
+==========
+
+* System Programming Manual: 39.1.4 Intel® SGX Launch Control Configuration