linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org
Cc: akpm@linux-foundation.org, dave.hansen@intel.com,
	sean.j.christopherson@intel.com, nhorman@redhat.com,
	npmccallum@redhat.com, haitao.huang@intel.com,
	andriy.shevchenko@linux.intel.com, tglx@linutronix.de,
	kai.svahn@intel.com, bp@alien8.de, josh@joshtriplett.org,
	luto@kernel.org, kai.huang@intel.com, rientjes@google.com,
	cedric.xing@intel.com, puiterwijk@redhat.com,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	linux-doc@vger.kernel.org, Randy Dunlap <rdunlap@infradead.org>
Subject: [PATCH v30 19/20] docs: x86/sgx: Document SGX micro architecture and kernel internals
Date: Fri, 15 May 2020 03:44:09 +0300	[thread overview]
Message-ID: <20200515004410.723949-20-jarkko.sakkinen@linux.intel.com> (raw)
In-Reply-To: <20200515004410.723949-1-jarkko.sakkinen@linux.intel.com>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 9760 bytes --]

Document the Intel SGX kernel architecture. The fine-grained micro
architecture details can be looked up from Intel SDM Volume 3D.

Cc: linux-doc@vger.kernel.org
Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 Documentation/x86/index.rst |   1 +
 Documentation/x86/sgx.rst   | 206 ++++++++++++++++++++++++++++++++++++
 2 files changed, 207 insertions(+)
 create mode 100644 Documentation/x86/sgx.rst

diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index 265d9e9a093b..807290bf357c 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -30,3 +30,4 @@ x86-specific Documentation
    usb-legacy-support
    i386/index
    x86_64/index
+   sgx
diff --git a/Documentation/x86/sgx.rst b/Documentation/x86/sgx.rst
new file mode 100644
index 000000000000..9609a3409ad1
--- /dev/null
+++ b/Documentation/x86/sgx.rst
@@ -0,0 +1,206 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+Architecture
+============
+
+*Software Guard eXtensions (SGX)* is a set of instructions that enable ring-3
+applications to set aside private regions of code and data. These regions are
+called enclaves. An enclave can be entered to a fixed set of entry points. Only
+a CPU running inside the enclave can access its code and data.
+
+The support can be determined by
+
+	``grep sgx /proc/cpuinfo``
+
+Enclave Page Cache
+==================
+
+SGX utilizes an *Enclave Page Cache (EPC)* to store pages that are associated
+with an enclave. It is contained in a BIOS reserved region of physical memory.
+Unlike pages used for regular memory, pages can only be accessed outside the
+enclave for different purposes with the instructions **ENCLS**, **ENCLV** and
+**ENCLU**.
+
+Direct memory accesses to an enclave can be only done by a CPU executing inside
+the enclave. An enclave can be entered with **ENCLU[EENTER]** to a fixed set of
+entry points. However, a CPU executing inside the enclave can do outside memory
+accesses.
+
+Page Types
+----------
+
+**SGX Enclave Control Structure (SECS)**
+   Enclave's address range, attributes and other global data are defined
+   by this structure.
+
+**Regular (REG)**
+   Regular EPC pages contain the code and data of an enclave.
+
+**Thread Control Structure (TCS)**
+   Thread Control Structure pages define the entry points to an enclave and
+   track the execution state of an enclave thread.
+
+**Version Array (VA)**
+   Version Array pages contain 512 slots, each of which can contain a version
+   number for a page evicted from the EPC.
+
+Enclave Page Cache Map
+----------------------
+
+The processor tracks EPC pages via the *Enclave Page Cache Map (EPCM)*.  EPCM
+contains an entry for each EPC page, which describes the owning enclave, access
+rights and page type among the other things.
+
+The permissions from EPCM is consulted if and only if walking the kernel page
+tables succeeds. The total permissions are thus a conjunction between page table
+and EPCM permissions.
+
+For all intents and purposes the SGX architecture allows the processor to
+invalidate all EPCM entries at will, i.e. requires that software be prepared to
+handle an EPCM fault at any time. The contents of EPC are encrypted with an
+ephemeral key, which is lost on power transitions.
+
+EPC management
+==============
+
+EPC pages do not have ``struct page`` instances. They are IO memory from kernel
+perspective. The consequence is that they are always mapped as shared memory.
+Kernel defines ``/dev/sgx/enclave`` that can be mapped as ``MAP_SHARED`` to
+define the address range for an enclave.
+
+EPC Over-subscription
+=====================
+
+When the amount of free EPC pages goes below a low watermark the swapping thread
+starts reclaiming pages. The pages that do not have the **A** bit set are
+selected as victim pages.
+
+Launch Control
+==============
+
+SGX provides a launch control mechanism. After all enclave pages have been
+copied, kernel executes **ENCLS[EINIT]**, which initializes the enclave. Only
+after this the CPU can execute inside the enclave.
+
+This leaf function takes an RSA-3072 signature of the enclave measurement and an
+optional cryptographic token. Linux does not take advantage of launch tokens.
+The instruction checks that the signature is signed with the key defined in
+**IA32_SGXLEPUBKEYHASH?** MSRs and the measurement is correct. If so, the
+enclave is allowed to be executed.
+
+MSRs can be configured by the BIOS to be either readable or writable. Linux
+supports only writable configuration in order to give full control to the kernel
+on launch control policy. Readable configuration requires the use of previously
+mentioned launch tokens.
+
+The current kernel implementation supports only writable MSRs. The launch is
+performed by setting the MSRs to the hash of the enclave signer's public key.
+The alternative would be to have *a launch enclave* that would be signed with
+the key set into MSRs, which would then generate launch tokens for other
+enclaves. This would only make sense with read-only MSRs, and thus the option
+has been discarded.
+
+Attestation
+===========
+
+Local Attestation
+-----------------
+
+In local attestation an enclave creates a **REPORT** data structure with
+**ENCLS[EREPORT]**, which describes the origin of an enclave. In particular, it
+contains a AES-CMAC of the enclave contents signed with a report key unique to
+each processor. All enclaves have access to this key.
+
+This mechanism can also be used in addition as a communication channel as the
+**REPORT** data structure includes a 64-byte field for variable information.
+
+Remote Attestation
+------------------
+
+For remote attestation (or provisioning) there are schemes available:
+
+* EPID scheme, which requires the use of Intel managed attestation service.
+* ECDSA scheme, which allows a 3rd party to act as an attestation service.
+
+Intel has released an open source *Quoting Enclave (QE)* and *Provisioning
+Certification Enclave (PCE)* for the ECDSA based scheme. A PCE is used to
+certify the locally used QE's.
+
+Intel also provides a proprietary of the PCE. This is a necessary when one
+needs to be able to prove that an enclave is running on real hardware. To
+achieve this the enclave needs to be rooted to the Intel's PKI, which obviously
+cannot be exposed to 3rd parties.
+
+Both schemes require **ATTRIBUTES.PROVISIONKEY** but only EPID scheme uses the
+on-die provisioning key. This privilege should be under normal conditions given
+only to QE's because uncontrolled use of attestation could be used by malware
+for benefit.
+
+Encryption engines
+==================
+
+In order to conceal the enclave data while it is out of the CPU package,
+memory controller has to be extended with an encryption engine. MC can then
+route incoming requests coming from CPU cores running in enclave mode to the
+encryption engine.
+
+In CPUs prior to Icelake, Memory Encryption Engine (MEE) is used to
+encrypt pages leaving the CPU caches. MEE uses a n-ary Merkle tree with root in
+SRAM to maintain integrity of the encrypted data. This provides integrity and
+anti-replay protection but does not scale to large memory sizes because the time
+required to update the Merkle tree grows logarithmically in relation to the
+memory size.
+
+CPUs starting from Icelake use Total Memory Encryption (TME) in the place of
+MEE. TME throws away the Merkle tree, which means losing integrity and
+anti-replay protection but also enables variable size memory pools for EPC.
+Using this attack for benefit would require an interposer on the system bus.
+
+Backing storage
+===============
+
+Backing storage is shared and not accounted. It is implemented as a private
+shmem file. Providing a backing storage in some form from user space is not
+possible - accounting would go to invalid state as reclaimed pages would get
+accounted to the processes of which behalf the kernel happened to be acting on.
+
+Access control
+==============
+
+`mmap()` permissions are capped by the enclave permissions. A direct
+consequence of this is that all the pages for an address range must be added
+before `mmap()` can be applied. Effectively an enclave page with minimum
+permission in the address range sets the permission cap for the mapping
+operation.
+
+Usage Models
+============
+
+Shared Library
+--------------
+
+Sensitive data and the code that acts on it is partitioned from the application
+into a separate library. The library is then linked as a DSO which can be loaded
+into an enclave. The application can then make individual function calls into
+the enclave through special SGX instructions. A run-time within the enclave is
+configured to marshal function parameters into and out of the enclave and to
+call the correct library function.
+
+Application Container
+---------------------
+
+An application may be loaded into a container enclave which is specially
+configured with a library OS and run-time which permits the application to run.
+The enclave run-time and library OS work together to execute the application
+when a thread enters the enclave.
+
+References
+==========
+
+"Intel® Software Guard Extensions: EPID Provisioning and Attestation Services"
+   https://software.intel.com/sites/default/files/managed/57/0e/ww10-2016-sgx-provisioning-and-attestation-final.pdf
+
+"Supporting Third Party Attestation for Intel® SGX with Intel® Data Center
+Attestation Primitives"
+   https://software.intel.com/sites/default/files/managed/f1/b8/intel-sgx-support-for-third-party-attestation.pdf
-- 
2.25.1


  parent reply	other threads:[~2020-05-15  0:47 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-15  0:43 [PATCH v30 00/20] Intel SGX foundations Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 01/20] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2020-05-20 12:16   ` Borislav Petkov
2020-05-20 14:00     ` Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 02/20] x86/cpufeatures: x86/msr: Intel SGX Launch Control " Jarkko Sakkinen
2020-05-20 12:23   ` Borislav Petkov
2020-05-20 14:04     ` Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 03/20] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 04/20] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2020-05-20 18:47   ` Borislav Petkov
2020-05-20 21:04     ` Sean Christopherson
2020-05-22 15:54     ` Jarkko Sakkinen
2020-05-22 16:13       ` Sean Christopherson
2020-05-22 19:50         ` Jarkko Sakkinen
2020-05-25  8:20           ` Borislav Petkov
2020-05-27 19:43             ` Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 05/20] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 06/20] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 07/20] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2020-05-25  9:23   ` Borislav Petkov
2020-05-27  3:56     ` Sean Christopherson
2020-05-27 20:35       ` Borislav Petkov
2020-05-28  7:36         ` Jarkko Sakkinen
2020-05-28  5:25       ` Jarkko Sakkinen
2020-05-28  5:35         ` Jarkko Sakkinen
2020-05-28  6:14           ` Jarkko Sakkinen
2020-05-28  6:16             ` Jarkko Sakkinen
2020-05-28  5:13     ` Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 08/20] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2020-05-26 12:52   ` Borislav Petkov
2020-05-27  4:21     ` Sean Christopherson
2020-05-27 20:46       ` Borislav Petkov
2020-05-28  0:52         ` Sean Christopherson
2020-05-28  6:51           ` Jarkko Sakkinen
2020-05-28  1:23         ` Jarkko Sakkinen
2020-05-28  1:36           ` Sean Christopherson
2020-05-28  6:52             ` Jarkko Sakkinen
2020-05-28 17:16               ` Borislav Petkov
2020-05-28 17:19                 ` Sean Christopherson
2020-05-28 17:27                   ` Borislav Petkov
2020-05-28 17:34                     ` Sean Christopherson
2020-05-28 19:07                 ` Jarkko Sakkinen
2020-05-28 19:59                   ` Sean Christopherson
2020-05-29  3:28                     ` Jarkko Sakkinen
2020-05-29  3:37                       ` Sean Christopherson
2020-05-29  5:07                         ` Jarkko Sakkinen
2020-05-29  8:12                         ` Jarkko Sakkinen
2020-05-29  8:13                           ` Jarkko Sakkinen
2020-05-29  3:38                       ` Jarkko Sakkinen
2020-05-15  0:43 ` [PATCH v30 09/20] mm: Introduce vm_ops->may_mprotect() Jarkko Sakkinen
2020-05-29 12:10   ` Borislav Petkov
2020-05-29 18:18     ` Jarkko Sakkinen
2020-05-29 18:28   ` Dave Hansen
2020-05-31 23:12     ` Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 10/20] x86/sgx: Linux Enclave Driver Jarkko Sakkinen
2020-05-21 19:12   ` Sean Christopherson
2020-05-22 19:26     ` Jarkko Sakkinen
2020-05-22 19:39     ` Jarkko Sakkinen
2020-05-22  3:33   ` Sean Christopherson
2020-05-15  0:44 ` [PATCH v30 11/20] x86/sgx: Add provisioning Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 12/20] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-05-22  6:58   ` Sean Christopherson
2020-05-22 19:57     ` Jarkko Sakkinen
2020-05-22 21:52       ` Sean Christopherson
2020-05-22  7:15   ` Sean Christopherson
2020-05-22 19:47     ` Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 13/20] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 14/20] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 15/20] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 16/20] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 17/20] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
2020-05-15  0:44 ` [PATCH v30 18/20] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2020-05-15  0:44 ` Jarkko Sakkinen [this message]
2020-05-15  0:44 ` [PATCH v30 20/20] x86/sgx: Update MAINTAINERS Jarkko Sakkinen
2020-05-16  8:57 ` [PATCH] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200515004410.723949-20-jarkko.sakkinen@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=josh@joshtriplett.org \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=puiterwijk@redhat.com \
    --cc=rdunlap@infradead.org \
    --cc=rientjes@google.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).