Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp825325ybt; Wed, 17 Jun 2020 15:11:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0mR2SZoOsSh5XEz834vfZjILZoQOgbkQGPjsmPmZtm7FgHLQRKEfEWO29q38exaPDUxQD X-Received: by 2002:a17:907:9f0:: with SMTP id ce16mr1178794ejc.476.1592431918437; Wed, 17 Jun 2020 15:11:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592431918; cv=none; d=google.com; s=arc-20160816; b=tAvOcXDIYRubh6EyU4GqCq4wkCYzp8+QyB+ztVNpvA/1P3mii5AT3KU2bx6RjIiBso KZ8hQi5ipfxpgEYXsdjAADDAcwHgEbPMbwR5xJJKCU8+CRCwxbzcMdLpzcJ9NGTsLxOl NrcYxjZYqm1zVuPNrM4a4stZhlcWW1DEySCuZaGeXYu0lBonsh4aGdt8XF09eZOg6bs9 SYvvusc79FBqSyTzCB+BWmkYbYv8HD0qQacoMw+C+reJNWu6XRcGxDyF997pifvQI86/ ePmr+S1xtBxRsDJXpVzBp4JUPdqDFzuC5rtbai63CU6co4cqZyhX+4+96uqJuRo/p7wD ziDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :ironport-sdr:ironport-sdr; bh=REP80qVmpRFof1leTOtx9y+rNoMPvGhmt+WNmAIny7w=; b=QbJ5S1aaWSlnh2MGWKBkng+dOmpvCyrfUF3mopxDeBITW7xR267HbtcTV1+z423RsE SdCQZEMNLD6qERdnFJ7Cw/gCsQ+WMO4+l1/7nSUoqZQZ4ZizzLnG9MYN7uHT3Su9pYz6 ktJFOESwu/9OU8wRbvZHj+jZW5xkL0POpSw9ek7evtFxljx5uMJ9/bJ7uguUsTkwFCV/ 2GG9ar2TQwYO1zkFTDFdUM5Fr2YWuajIHM/eUvTC/JkzmYD0NDTp5E6ViF8lY/lioRk1 QVOD8OA8yvSkm6P5Nc2Z3kNmD0zPajEoZWx1DMTt+TBOeO/P+zTua/U7tm+W0Oz3slvO XBSg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f17si634298ejh.246.2020.06.17.15.11.35; Wed, 17 Jun 2020 15:11:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727020AbgFQWJn (ORCPT + 99 others); Wed, 17 Jun 2020 18:09:43 -0400 Received: from mga17.intel.com ([192.55.52.151]:6776 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726761AbgFQWJn (ORCPT ); Wed, 17 Jun 2020 18:09:43 -0400 IronPort-SDR: LzISDdAfkwhv91AI3pOrdTaihqS2++aGQgzh36nb/4j49IdmpqLNrEt3Pk8xO5iOjRrQFqoSIQ UD6Kw5DG/1uQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2020 15:09:42 -0700 IronPort-SDR: OKpSvoY6XScPQyXwVwCy566jnRcZjOxQqudcA3tB2iS7nq6Spa2edilQvkDEg2leDyK93G1Cl5 bIRYNfjAeCeQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,523,1583222400"; d="scan'208";a="421287854" Received: from ysharon1-mobl1.ger.corp.intel.com (HELO localhost) ([10.252.49.131]) by orsmga004.jf.intel.com with ESMTP; 17 Jun 2020 15:09:30 -0700 From: Jarkko Sakkinen To: x86@kernel.org, linux-sgx@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Sean Christopherson , Jethro Beekman , Jarkko Sakkinen , akpm@linux-foundation.org, andriy.shevchenko@linux.intel.com, asapek@google.com, bp@alien8.de, cedric.xing@intel.com, chenalexchen@google.com, conradparker@google.com, cyhanish@google.com, dave.hansen@intel.com, haitao.huang@intel.com, josh@joshtriplett.org, kai.huang@intel.com, kai.svahn@intel.com, kmoy@google.com, ludloff@google.com, luto@kernel.org, nhorman@redhat.com, npmccallum@redhat.com, puiterwijk@redhat.com, rientjes@google.com, tglx@linutronix.de, yaozhangx@google.com Subject: [PATCH v33 03/21] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Date: Thu, 18 Jun 2020 01:08:25 +0300 Message-Id: <20200617220844.57423-4-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200617220844.57423-1-jarkko.sakkinen@linux.intel.com> References: <20200617220844.57423-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) Acked-by: Jethro Beekman 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 714b1a30e7b0..ee3617b67bf4 100644 --- a/arch/x86/include/asm/traps.h +++ b/arch/x86/include/asm/traps.h @@ -58,5 +58,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 66be9bd60307..25d48aae36c1 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1055,6 +1055,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