From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8406EC55190 for ; Tue, 21 Apr 2020 21:53:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6A87920724 for ; Tue, 21 Apr 2020 21:53:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726501AbgDUVxw (ORCPT ); Tue, 21 Apr 2020 17:53:52 -0400 Received: from mga09.intel.com ([134.134.136.24]:43046 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726421AbgDUVxp (ORCPT ); Tue, 21 Apr 2020 17:53:45 -0400 IronPort-SDR: XG8yASRAQZbywCyBUcRIDTQHqrT0kFHP7Mo4wDDrrxTNp3f1PSh2Fv30GXWYLasa5orA6VHMNB /7zumeyPQqAA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 21 Apr 2020 14:53:44 -0700 IronPort-SDR: 2y6YPe61+nOLxCseZs1ruUbkEDDO7CyVk49dem1kKqeoeuyvxYNHpLhUuSwZy+I59Qs1axj814 1fxV0Y8jBP/A== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,411,1580803200"; d="scan'208";a="456260566" Received: from mnchalux-mobl2.gar.corp.intel.com (HELO localhost) ([10.252.44.234]) by fmsmga005.fm.intel.com with ESMTP; 21 Apr 2020 14:53:40 -0700 From: Jarkko Sakkinen 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 Subject: [PATCH v29 04/20] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Date: Wed, 22 Apr 2020 00:53:00 +0300 Message-Id: <20200421215316.56503-5-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200421215316.56503-1-jarkko.sakkinen@linux.intel.com> References: <20200421215316.56503-1-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson 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 Signed-off-by: Jarkko Sakkinen --- 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.25.1