Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp282703ybg; Mon, 1 Jun 2020 00:55:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwFulpyeva5MUzJ0OhTvVG2jFBp2Mbo87b+HR4OEYCT0LQ3sRbg4z+8AAh8b7kWrDnFU7F3 X-Received: by 2002:a05:6402:1770:: with SMTP id da16mr19743224edb.122.1590998111418; Mon, 01 Jun 2020 00:55:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590998111; cv=none; d=google.com; s=arc-20160816; b=ZZ2F9BdFosKQIgR57rr1TvjmRYThEUmJ0Ie1dwS+ED7bBrEKrmZS069tHGCJNc3ffX sII7gnCFY7TDTNphsrz07q7zMURbpUaDZH/p7rBbsyyi1a1JZCPhw6ht87L1PppXKJjq vc6j+RFrrBAa39CQSgleaqlfKqd3Zyg/KLlfPh6Tx0594xDZ84F+jhWABfWaEzOqnts1 4/Q6iMM+Y3mfu9KX1Ua07jGI8XbfaWBbT1s3/QYtPdaGirH1spqKSjuBUryw+j1AgL01 xwQRiOoltCRjTmrHCicNUbcmcrWs+sxoCIkuQYuo+fq+WmZf6kvK4O0GwzDQ3E+Q70cL JEQQ== 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=X/Rj5/Ay4+Yf7Cw6CspIpkqtwhsS7h1O/Vu3iqD+oNE=; b=NwM38oXrOjgZvyv1ECuMiFrrmCp1J77sGNlJQEj5YJnTkILJ0yZTLlG17iGlCR6T7R 8CTy5qe6aiejgaDpdrW6inKXtf7k1CpFE7/7YMebAqqSg3g/ng8u1qoUZ5d0mXu2CcZa tlX+hHnyUiE9oP4rtHWSiiYqRXC5gr35IyQXZn6dNj2H2XouXvKc9v/h5xkw1Peg+cKd tpyiElLbErQ7SNutDk2z9vyGn0YZH+0CfAie63hegV670NX3iPmSKt9/kMcdIDVKqcyg 5cBqdnx00mS0lJ8ZRumI2EAkBiEKYjsHzX3z9OAu1CRvlr+ym+tA+giq8gxyk4SdhdK4 QV+w== 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 4si9929169edw.72.2020.06.01.00.54.48; Mon, 01 Jun 2020 00:55:11 -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 S1728216AbgFAHwv (ORCPT + 99 others); Mon, 1 Jun 2020 03:52:51 -0400 Received: from mga12.intel.com ([192.55.52.136]:20495 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725999AbgFAHwu (ORCPT ); Mon, 1 Jun 2020 03:52:50 -0400 IronPort-SDR: +/L0KEGg4+JmYihYS9Hp4kQzfqXZdSCBF2DJBKhiEKbvD5v8elbV6cO8Pd2+NWpQ4+qWEOoPBs ai4gFFf8ZlOQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jun 2020 00:52:50 -0700 IronPort-SDR: ZENFADukCaAAbiwEpdQOQCnE+MWwKzsbRYO4s48SXz4WquW1XJ+3jTtQvL4NxYpt133NGqC9Pl BIlmedTwh7BQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,460,1583222400"; d="scan'208";a="311879489" Received: from yhanin-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.43.17]) by FMSMGA003.fm.intel.com with ESMTP; 01 Jun 2020 00:52:44 -0700 From: Jarkko Sakkinen To: linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org Cc: 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 v32 03/21] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Date: Mon, 1 Jun 2020 10:52:00 +0300 Message-Id: <20200601075218.65618-4-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200601075218.65618-1-jarkko.sakkinen@linux.intel.com> References: <20200601075218.65618-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 c26a7e1d8a2c..07dd9f74d65a 100644 --- a/arch/x86/include/asm/traps.h +++ b/arch/x86/include/asm/traps.h @@ -171,5 +171,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 a51df516b87b..16c53c874bb9 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1201,6 +1201,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