Add a section on how EPC is managed and why. Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx> --- Documentation/x86/sgx/2.Kernel-internals.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/Documentation/x86/sgx/2.Kernel-internals.rst b/Documentation/x86/sgx/2.Kernel-internals.rst index de359bf605ca..5c90a65936f2 100644 --- a/Documentation/x86/sgx/2.Kernel-internals.rst +++ b/Documentation/x86/sgx/2.Kernel-internals.rst @@ -15,6 +15,26 @@ 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. +EPC management +============== + +Because the kernel can't arbitrarily read EPC memory or share RO backing pages +between enclaves, traditional memory models such as CoW and fork() do not work +with enclaves. In other words, the architectural rules of EPC forces it to be +treated as MAP_SHARED at all times. + +The inability to employ traditional memory models also means that EPC memory +must be isolated from normal memory pools, e.g. attempting to use EPC memory +for normal mappings would result in faults and/or perceived data corruption. +Furthermore, EPC is not enumerated by as normal memory, e.g. BIOS enumerates +EPC as reserved memory in the e820 tables, or not at all. As a result, EPC +memory is directly managed by the SGX subsystem, e.g. SGX employs VM_PFNMAP to +manually insert/zap/swap page table entries, and exposes EPC to userspace via +a well known device, /dev/sgx/enclave. + +The net effect is that all enclave VMAs must be MAP_SHARED and are backed by +a single file, /dev/sgx/enclave. + EPC oversubscription ==================== -- 2.22.0
