Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp1357060pxb; Wed, 4 Nov 2020 06:57:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJyvtIwMQYQNKjiHBBT0CLBS3JZJUgTYCDHfYr7q99G/68g/Ujf9C62+ZoT435XXx4CyFSom X-Received: by 2002:a17:906:12cf:: with SMTP id l15mr26699159ejb.540.1604501849006; Wed, 04 Nov 2020 06:57:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1604501848; cv=none; d=google.com; s=arc-20160816; b=BAdYUWOG6HvTiWcQ31ujHYVZVrc3YFJdyT68+X+oqYxPjK5/cKYLBVnalu5Kham7Xb /ModSGGPN2Epi/SAQbPGp1ZNVzxFaxRkbYUPYg02Ie0DlrycyN2NXagwMbfEU3RWyccH 3uAYoXotk5+uC61GXgeZPpA+ZHc+/EPaYS6qEUgMYrxzjz7IDE2+2KctQmafxziwUR4Y ZNxqH06hfmXXY1ZpB43EJGcpIM8Kyd91reLs0Bghha6hCv+L5/8O/s38ldeY1UBdC5oa dz6BweJ3mlUQ1QLsw3K6xX9i08UdPHRZ8Pg28gYwN+MC1pim1eMX41ilV0nDuO6uCDDv 33xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=11EwJXol3qFIWGH9c5752CysYRWPKTNI9UV/nzlA2AE=; b=svnOMWKqDm6OSTfpZGmqbGxBCji8cuy8RHA1Z5iKwvSJvqtdqW6krApMtHDLxVi2vv w9K4yBHFroEURiHRLUFHVLPv/o0fnocJvWS5GNiR5dSM4gzdnOJpL2HqjL06Savs4NLq ApHIOZUQcQuAL5gInDwZfXXxzaYwOI5YOLZNIKDfJwq+QWGV3FJfFWarlKjjJbcjLaAX g5IpWtBGIcDpInovjpMK9pffNAKGBAaJcoXjk45EP0rpewJ+iVcg0ai4CvIbr17sSe5Q 6la/uR+FNDqdiUrjt2iOaQljJ5/dHP26Uymz8uawtb1PA5rZHd57IPLFPFtPOGAewPTN n7KQ== 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 v24si1390868edq.0.2020.11.04.06.57.05; Wed, 04 Nov 2020 06:57:28 -0800 (PST) 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 S1730257AbgKDOzS (ORCPT + 99 others); Wed, 4 Nov 2020 09:55:18 -0500 Received: from mail.kernel.org ([198.145.29.99]:49034 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730245AbgKDOzP (ORCPT ); Wed, 4 Nov 2020 09:55:15 -0500 Received: from suppilovahvero.lan (83-245-197-237.elisa-laajakaista.fi [83.245.197.237]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 91A98221F8; Wed, 4 Nov 2020 14:55:09 +0000 (UTC) From: Jarkko Sakkinen To: x86@kernel.org, linux-sgx@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Sean Christopherson , Jethro Beekman , Darren Kenny , Borislav Petkov , 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, 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, mikko.ylinen@intel.com Subject: [PATCH v40 06/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Date: Wed, 4 Nov 2020 16:54:12 +0200 Message-Id: <20201104145430.300542-7-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201104145430.300542-1-jarkko.sakkinen@linux.intel.com> References: <20201104145430.300542-1-jarkko.sakkinen@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sean Christopherson The x86 architecture has a set of page fault error codes. These indicate things like whether the fault occurred from a write, or whether it originated in userspace. The SGX hardware architecture has its own per-page memory management metadata (EPCM) [*] and hardware which is separate from the normal x86 MMU. The architecture has a new page fault error code: PF_SGX. This new error code bit is set whenever a page fault occurs as the result of the SGX MMU. These faults occur for a variety of reasons. For instance, an access attempt to enclave memory from outside the enclave causes a PF_SGX fault. PF_SGX would also be set for permission conflicts, such as if a write to an enclave page occurs and the page is marked read-write in the x86 page tables but is read-only in the EPCM. These faults do not always indicate errors, though. SGX pages are encrypted with a key that is destroyed at hardware reset, including suspend. Throwing a SIGSEGV allows user space software to react and recover when these events occur. Include PF_SGX in the PF error codes list and throw SIGSEGV when it is encountered. [*] Intel SDM: 36.5.1 Enclave Page Cache Map (EPCM) Acked-by: Jethro Beekman Reviewed-by: Darren Kenny Reviewed-by: Borislav Petkov Signed-off-by: Sean Christopherson Signed-off-by: Jarkko Sakkinen --- arch/x86/include/asm/trap_pf.h | 1 + arch/x86/mm/fault.c | 12 ++++++++++++ 2 files changed, 13 insertions(+) diff --git a/arch/x86/include/asm/trap_pf.h b/arch/x86/include/asm/trap_pf.h index 305bc1214aef..1794777b2a85 100644 --- a/arch/x86/include/asm/trap_pf.h +++ b/arch/x86/include/asm/trap_pf.h @@ -19,6 +19,7 @@ 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_TRAP_PF_H */ diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 82bf37a5c9ec..9339fee83784 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1101,6 +1101,18 @@ access_error(unsigned long error_code, struct vm_area_struct *vma) if (error_code & X86_PF_PK) return 1; + /* + * SGX hardware blocked the access. This usually happens + * when the enclave memory contents have been destroyed, like + * after a suspend/resume cycle. In any case, the kernel can't + * fix the cause of the fault. Handle the fault as an access + * error even in cases where no actual access violation + * occurred. This allows userspace to rebuild the enclave in + * response to the signal. + */ + 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.27.0