From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org
Subject: Re: [PATCH for_v21] docs: x86/sgx: Add a blurb on basic EPC management to 'kernel internals'
Date: Fri, 12 Jul 2019 06:47:52 +0300 [thread overview]
Message-ID: <20190712034752.2grjs2uyjssa2cd3@linux.intel.com> (raw)
In-Reply-To: <20190711214417.16565-1-sean.j.christopherson@intel.com>
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
prev parent reply other threads:[~2019-07-12 3:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 21:44 [PATCH for_v21] docs: x86/sgx: Add a blurb on basic EPC management to 'kernel internals' Sean Christopherson
2019-07-12 3:47 ` Jarkko Sakkinen [this message]
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=20190712034752.2grjs2uyjssa2cd3@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=sean.j.christopherson@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.