| Message ID | 20190711214417.16565-1-sean.j.christopherson@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [for_v21] docs: x86/sgx: Add a blurb on basic EPC management to 'kernel internals' | expand |
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@intel.com> > --- > 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@linux.intel.com> /Jarkko
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 ====================
Add a section on how EPC is managed and why. Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> --- Documentation/x86/sgx/2.Kernel-internals.rst | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)