linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: linux-kernel@vger.kernel.org, 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, 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, kai.huang@intel.com, rientjes@google.com,
	cedric.xing@intel.com, puiterwijk@redhat.com,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Subject: [PATCH v25 03/21] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX
Date: Tue,  4 Feb 2020 08:05:27 +0200	[thread overview]
Message-ID: <20200204060545.31729-4-jarkko.sakkinen@linux.intel.com> (raw)
In-Reply-To: <20200204060545.31729-1-jarkko.sakkinen@linux.intel.com>

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

Include SGX bit to the PF error codes and throw SIGSEGV with PF_SGX when
a #PF with SGX set happens.

CPU throws a #PF with the SGX bit in the event of Enclave Page Cache Map
(EPCM) conflict. The EPCM is a CPU-internal table, which describes the
properties for a enclave page. Enclaves are measured and signed software
entities, which SGX hosts. [1]

Although the primary purpose of the EPCM conflict checks  is to prevent
malicious accesses to an enclave, an illegit access can happen also for
legit reasons.

All SGX reserved memory, including EPCM is encrypted with a transient
key that does not survive from the power transition. Throwing a SIGSEGV
allows user space software react when this happens (e.g. rec-create the
enclave, which was invalidated).

[1] Intel SDM: 36.5.1 Enclave Page Cache Map (EPCM)

Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 arch/x86/include/asm/traps.h |  1 +
 arch/x86/mm/fault.c          | 13 +++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h
index ffa0dc8a535e..bb8d5ae74dbc 100644
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -174,5 +174,6 @@ enum x86_pf_error_code {
 	X86_PF_RSVD	=		1 << 3,
 	X86_PF_INSTR	=		1 << 4,
 	X86_PF_PK	=		1 << 5,
+	X86_PF_SGX	=		1 << 15,
 };
 #endif /* _ASM_X86_TRAPS_H */
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index fa4ea09593ab..dee9504cde79 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1179,6 +1179,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 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.20.1


  parent reply	other threads:[~2020-02-04  6:06 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-04  6:05 [PATCH v25 00/21] Intel SGX foundations Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 01/21] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 02/21] x86/cpufeatures: x86/msr: Intel SGX Launch Control " Jarkko Sakkinen
2020-02-04  6:05 ` Jarkko Sakkinen [this message]
2020-02-04  6:05 ` [PATCH v25 04/21] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 05/21] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 06/21] x86/cpu/intel: Detect SGX supprt Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 07/21] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen
2020-02-05 19:57   ` Sean Christopherson
2020-02-05 23:11     ` Jarkko Sakkinen
2020-02-06 15:34       ` Jarkko Sakkinen
2020-02-06 15:35     ` Jarkko Sakkinen
2020-02-06 15:55       ` Sean Christopherson
2020-02-04  6:05 ` [PATCH v25 08/21] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 09/21] mm: Introduce vm_ops->may_mprotect() Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 10/21] x86/sgx: Linux Enclave Driver Jarkko Sakkinen
2020-02-04  6:18   ` Jarkko Sakkinen
2020-02-05 15:58   ` Haitao Huang
2020-02-07 17:03   ` Haitao Huang
2020-02-04  6:05 ` [PATCH v25 11/21] selftests/x86: Recurse into subdirectories Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 12/21] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 13/21] x86/sgx: Add provisioning Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 14/21] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 15/21] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 16/21] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 17/21] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 18/21] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 19/21] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 20/21] selftests/x86: Add vDSO selftest for SGX Jarkko Sakkinen
2020-02-04  6:05 ` [PATCH v25 21/21] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
2020-02-05 17:54   ` Randy Dunlap
2020-02-05 23:07     ` Jarkko Sakkinen
2020-02-05 23:10       ` Randy Dunlap
2020-02-06 14:50         ` Jarkko Sakkinen
2020-02-04 15:11 ` [PATCH v25 00/21] Intel SGX foundations Sean Christopherson
2020-02-05 21:59   ` Jarkko Sakkinen
2020-02-05 23:09     ` Jarkko Sakkinen
2020-02-05 16:01 ` Haitao Huang
2020-02-05 22:01   ` 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=20200204060545.31729-4-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=cedric.xing@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=josh@joshtriplett.org \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=puiterwijk@redhat.com \
    --cc=rientjes@google.com \
    --cc=sean.j.christopherson@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).