linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: 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, serge.ayoun@intel.com,
	shay.katz-zamir@intel.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, Andy Lutomirski <luto@amacapital.net>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Subject: [PATCH v18 07/25] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX
Date: Sat, 22 Dec 2018 01:11:36 +0200	[thread overview]
Message-ID: <20181221231154.6120-8-jarkko.sakkinen@linux.intel.com> (raw)
In-Reply-To: <20181221231154.6120-1-jarkko.sakkinen@linux.intel.com>

From: Sean Christopherson <sean.j.christopherson@intel.com>

The PF_SGX bit is set if and only if the #PF is detected by the SGX
Enclave Page Cache Map (EPCM).  The EPCM is a hardware-managed table
that enforces accesses to an enclave's EPC pages in addition to the
software-managed kernel page tables, i.e. the effective permissions
for an EPC page are a logical AND of the kernel's page tables and
the corresponding EPCM entry.

The EPCM is consulted only after an access walks the kernel's page
tables, i.e.:

  a. the access was allowed by the kernel
  b. the kernel's tables have become less restrictive than the EPCM
  c. the kernel cannot fixup the cause of the fault

Noteably, (b) implies that either the kernel has botched the EPC
mappings or the EPCM has been invalidated (see below).  Regardless of
why the fault occurred, userspace needs to be alerted so that it can
take appropriate action, e.g. restart the enclave.  This is reinforced
by (c) as the kernel doesn't really have any other reasonable option,
i.e. signalling SIGSEGV is actually the least severe action possible.

Although the primary purpose of the EPCM is to prevent a malicious or
compromised kernel from attacking an enclave, e.g. by modifying the
enclave's page tables, do not WARN on a #PF w/ PF_SGX set.  The SGX
architecture effectively allows the CPU to invalidate all EPCM entries
at will and requires that software be prepared to handle an EPCM fault
at any time.  The architecture defines this behavior because the EPCM
is encrypted with an ephemeral key that isn't exposed to software.  As
such, the EPCM entries cannot be preserved across transitions that
result in a new key being used, e.g. CPU power down as part of an S3
transition or when a VM is live migrated to a new physical system.

Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/mm/fault.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 71d4b9d4d43f..eb8db2425b5b 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1108,6 +1108,19 @@ access_error(unsigned long error_code, struct vm_area_struct *vma)
 	if (error_code & X86_PF_PK)
 		return 1;
 
+	/*
+	 * Access is blocked by the Enclave Page Cache Map (EPCM), i.e. the
+	 * access is allowed by the PTE but not the EPCM.  This usually happens
+	 * when the EPCM is yanked out from under us, e.g. by hardware after a
+	 * suspend/resume cycle.  In any case, software, i.e. the kernel, can't
+	 * fix the source of the fault as the EPCM can't be directly modified
+	 * by software.  Handle the fault as an access error in order to signal
+	 * userspace, e.g. so that userspace can rebuild their enclave(s), even
+	 * though userspace may not have actually violated access permissions.
+	 */
+	if (unlikely(error_code & X86_PF_SGX))
+		return 1;
+
 	/*
 	 * Make sure to check the VMA so that we do not perform
 	 * faults just to hit a X86_PF_PK as soon as we fill in a
-- 
2.19.1


  parent reply	other threads:[~2018-12-21 23:13 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-21 23:11 [PATCH v18 00/25] Intel SGX1 support Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 01/25] x86/cpufeatures: Add Intel-defined SGX feature bit Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 02/25] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits) Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 03/25] x86/msr: Add IA32_FEATURE_CONTROL.SGX_ENABLE definition Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 04/25] x86/cpufeatures: Add Intel-defined SGX_LC feature bit Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 05/25] x86/msr: Add SGX Launch Control MSR definitions Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 06/25] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit Jarkko Sakkinen
2018-12-21 23:11 ` Jarkko Sakkinen [this message]
2018-12-21 23:11 ` [PATCH v18 08/25] x86/cpu/intel: Detect SGX support and update caps appropriately Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 09/25] x86/sgx: Define SGX1 and SGX2 ENCLS leafs Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 10/25] x86/sgx: Add ENCLS architectural error codes Jarkko Sakkinen
2018-12-24  5:17   ` Jethro Beekman
2018-12-24 11:53     ` Jarkko Sakkinen
2019-01-02 20:54     ` Sean Christopherson
2018-12-21 23:11 ` [PATCH v18 11/25] x86/sgx: Add SGX1 and SGX2 architectural data structures Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 12/25] x86/sgx: Add definitions for SGX's CPUID leaf and variable sub-leafs Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 13/25] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 14/25] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 15/25] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 16/25] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 17/25] x86/mpx: pass @mm to kernel_managing_mpx_tables() in mpx_notify_unmap() Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 18/25] x86/sgx: Add the Linux SGX Enclave Driver Jarkko Sakkinen
2018-12-24  5:36   ` Jethro Beekman
2018-12-24 11:55     ` Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 19/25] x86/sgx: Add provisioning Jarkko Sakkinen
2018-12-24  5:36   ` Jethro Beekman
2018-12-24 11:57     ` Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 20/25] x86/sgx: Add swapping code to the SGX driver Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 21/25] x86/sgx: Add a simple swapper for the EPC memory manager Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 22/25] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 23/25] x86/sgx: SGX documentation Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 24/25] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2018-12-21 23:11 ` [PATCH v18 25/25] x86/sgx: Update MAINTAINERS 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=20181221231154.6120-8-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=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=haitao.huang@intel.com \
    --cc=josh@joshtriplett.org \
    --cc=kai.svahn@intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=serge.ayoun@intel.com \
    --cc=shay.katz-zamir@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).