On Thu, Jul 11, 2019 at 02:44:17PM -0700, Sean Christopherson wrote: > 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 > Acked-by: Jarkko Sakkinen <jarkko.sakkinen@xxxxxxxxxxxxxxx> /Jarkko
