From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> To: <x86@kernel.org>, <platform-driver-x86@vger.kernel.org>, <linux-sgx@vger.kernel.org> Cc: <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>, <mark.shanahan@intel.com>, <andriy.shevchenko@linux.intel.com>, "Andy Lutomirski" <luto@amacapital.net>, Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, "open list:X86 MM" <linux-kernel@vger.kernel.org> Subject: [PATCH v15 07/23] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Date: Sat, 3 Nov 2018 01:11:06 +0200 [thread overview] Message-ID: <20181102231320.29164-8-jarkko.sakkinen@linux.intel.com> (raw) In-Reply-To: <20181102231320.29164-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> --- 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 47bebfe6efa7..11d16bcf6e64 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1153,6 +1153,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
WARNING: multiple messages have this Message-ID (diff)
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> To: x86@kernel.org, platform-driver-x86@vger.kernel.org, linux-sgx@vger.kernel.org Cc: 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, mark.shanahan@intel.com, andriy.shevchenko@linux.intel.com, Andy Lutomirski <luto@amacapital.net>, Dave Hansen <dave.hansen@linux.intel.com>, Andy Lutomirski <luto@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org (open list:X86 MM) Subject: [PATCH v15 07/23] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Date: Sat, 3 Nov 2018 01:11:06 +0200 [thread overview] Message-ID: <20181102231320.29164-8-jarkko.sakkinen@linux.intel.com> (raw) Message-ID: <20181102231106.CnNFuKJdD4Z-h-oWTzqns2FODYdrhxXVPw5Fe-4jlok@z> (raw) In-Reply-To: <20181102231320.29164-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> --- 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 47bebfe6efa7..11d16bcf6e64 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1153,6 +1153,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
next prev parent reply other threads:[~2018-11-02 23:11 UTC|newest] Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-02 23:10 [PATCH v15 00/23] Intel SGX1 Jarkko Sakkinen 2018-11-02 23:10 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 01/23] x86/sgx: Update MAINTAINERS Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 02/23] x86/cpufeatures: Add Intel-defined SGX feature bit Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:33 ` Borislav Petkov 2018-11-02 23:33 ` Borislav Petkov 2018-11-02 23:55 ` Jarkko Sakkinen 2018-11-02 23:55 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 03/23] x86/cpufeatures: Add SGX sub-features (as Linux-defined bits) Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 04/23] x86/msr: Add IA32_FEATURE_CONTROL.SGX_ENABLE definition Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 05/23] x86/cpu/intel: Detect SGX support and update caps appropriately Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-03 13:05 ` Andy Shevchenko 2018-11-03 13:05 ` Andy Shevchenko 2018-11-05 14:09 ` Jarkko Sakkinen 2018-11-05 14:09 ` Jarkko Sakkinen 2018-11-05 14:11 ` Jarkko Sakkinen 2018-11-05 14:11 ` Jarkko Sakkinen 2018-11-05 14:31 ` Andy Shevchenko 2018-11-05 14:31 ` Andy Shevchenko 2018-11-02 23:11 ` [PATCH v15 06/23] x86/mm: x86/sgx: Add new 'PF_SGX' page fault error code bit Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen [this message] 2018-11-02 23:11 ` [PATCH v15 07/23] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 08/23] x86/sgx: Define SGX1 and SGX2 ENCLS leafs Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 09/23] x86/sgx: Add ENCLS architectural error codes Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 10/23] x86/sgx: Add SGX1 and SGX2 architectural data structures Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 11/23] x86/sgx: Add definitions for SGX's CPUID leaf and variable sub-leafs Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-03 13:11 ` Andy Shevchenko 2018-11-03 13:11 ` Andy Shevchenko 2018-11-05 14:35 ` Jarkko Sakkinen 2018-11-05 14:35 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 12/23] x86/cpufeatures: Add Intel-defined SGX_LC feature bit Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 13/23] x86/msr: Add SGX Launch Control MSR definitions Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 14/23] x86/cpu/intel: Clear SGX_LC capability if not enabled in FEATURE_CONTROL Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-03 13:15 ` Andy Shevchenko 2018-11-03 13:15 ` Andy Shevchenko 2018-11-05 14:37 ` Jarkko Sakkinen 2018-11-05 14:37 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 15/23] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-03 13:17 ` Andy Shevchenko 2018-11-03 13:17 ` Andy Shevchenko 2018-11-05 17:30 ` Jarkko Sakkinen 2018-11-05 17:30 ` Jarkko Sakkinen 2018-11-05 20:39 ` Andy Shevchenko 2018-11-05 20:39 ` Andy Shevchenko 2018-11-06 12:03 ` Jarkko Sakkinen 2018-11-06 12:03 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 16/23] x86/sgx: Enumerate and track EPC sections Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-03 1:07 ` Jethro Beekman 2018-11-03 1:07 ` Jethro Beekman 2018-11-05 17:31 ` Jarkko Sakkinen 2018-11-05 17:31 ` Jarkko Sakkinen 2018-11-03 13:22 ` Andy Shevchenko 2018-11-03 13:22 ` Andy Shevchenko 2018-11-05 17:35 ` Jarkko Sakkinen 2018-11-05 17:35 ` Jarkko Sakkinen 2018-11-06 12:10 ` Jarkko Sakkinen 2018-11-06 12:10 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 17/23] x86/sgx: Add functions to allocate and free EPC pages Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 18/23] x86/sgx: Add sgx_einit() for initializing enclaves Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 19/23] platform/x86: Intel SGX driver Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 20/23] platform/x86: sgx: Add swapping functionality to the " Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 21/23] x86/sgx: Add a simple swapper for the EPC memory manager Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 22/23] platform/x86: ptrace() support for the SGX driver Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-02 23:11 ` [PATCH v15 23/23] x86/sgx: Driver documentation Jarkko Sakkinen 2018-11-02 23:11 ` Jarkko Sakkinen 2018-11-04 8:15 ` Mike Rapoport 2018-11-04 8:15 ` Mike Rapoport 2018-11-05 17:39 ` Jarkko Sakkinen 2018-11-05 17:39 ` Jarkko Sakkinen 2018-11-05 20:27 ` Dave Hansen 2018-11-05 20:27 ` Dave Hansen 2018-11-06 5:49 ` Jarkko Sakkinen 2018-11-06 5:49 ` Jarkko Sakkinen 2018-11-06 6:20 ` Jarkko Sakkinen 2018-11-06 6:20 ` Jarkko Sakkinen 2018-11-06 16:45 ` Dave Hansen 2018-11-06 16:45 ` Dave Hansen 2018-11-07 16:30 ` Jarkko Sakkinen 2018-11-07 16:30 ` Jarkko Sakkinen 2018-11-07 17:09 ` Dave Hansen 2018-11-07 17:09 ` Dave Hansen 2018-11-08 14:39 ` Jarkko Sakkinen 2018-11-08 14:39 ` Jarkko Sakkinen 2018-11-08 19:20 ` Jarkko Sakkinen 2018-11-08 19:20 ` Jarkko Sakkinen 2018-11-13 15:13 ` Jarkko Sakkinen 2018-11-06 6:26 ` Jarkko Sakkinen 2018-11-06 6:26 ` 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=20181102231320.29164-8-jarkko.sakkinen@linux.intel.com \ --to=jarkko.sakkinen@linux.intel.com \ --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=hpa@zytor.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-sgx@vger.kernel.org \ --cc=luto@amacapital.net \ --cc=luto@kernel.org \ --cc=mark.shanahan@intel.com \ --cc=mingo@redhat.com \ --cc=nhorman@redhat.com \ --cc=npmccallum@redhat.com \ --cc=peterz@infradead.org \ --cc=platform-driver-x86@vger.kernel.org \ --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: linkBe 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).