Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp695730pxb; Thu, 12 Nov 2020 14:04:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJwgE/NQA8p8WUjy2ddBOH584V7YFPSnswe1xhS7uAXyddBIL8l1YqHxn0hYGuxN1a/9kW48 X-Received: by 2002:a05:6402:3056:: with SMTP id bu22mr2150911edb.252.1605218692305; Thu, 12 Nov 2020 14:04:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605218692; cv=none; d=google.com; s=arc-20160816; b=hoD2aWc+2MhhF50gD2YmT4QjvCETYgL7aGHGHuRFopvmGlfNLFZcOXxwPntEqetel6 R6dqsZH4HgwnEvvKwxalfniJn9iex1pe8ONNIPHLs/6i3zNtUvv5fJ6jBadHvP1wa9+C KaIheCnU54fAOA3CqaXRzHD5wgiImXyTWmxbU0L0gPfonrvO5XyRwJu9CnnMttqmuAJa ux9bSUvNYTeBJ+qmpwd3QsK6qogLsLz1ktFr3/2Se2o7c96pn/qPQOdjOR9qTP1cmDjo WQL2XQxoRTdmZGmh7EwVRglnIqg6nOqgtsej7Us/X1nGxb5MvdcxmudRnXLfwaDAoglS ihAg== 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 :dkim-signature; bh=6q8JHcGkRK0HLdu8eCCpIqnb+It5dBxhQpegz2AKK8I=; b=WTTLyz8blNs7/8Zi9JqJW5qGLFur/lb3kJJYvK7NsgovPyOW2TXiPvh+WuEFErRvVH 5CPAJnEFAwM6vxEup+AewaE644OnwVmaGOR360zrCQhXBtbcwBf/ldb51qkBmRjoCvwK /cpdrlH5okClgqgpZnzyyk/ZsNRNPNlus2BdieddpLzAk8us4arbIdSgOTSl9BSja6gX EtqcUeyfxeHmsupP5YGTytFdiJ9aEJOjJJWDxlmJ0stKTh9Lwj7wpgxlMFerDeZnbmrN Zuz/8USxtGFhhmxar2YzX/XdYIGOdN8utjSHqjtO8hMLjAsd/NCQrBeqT9/Fxdfqmfmp 4ZKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=fT+L4yAa; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k20si5269063edk.392.2020.11.12.14.04.29; Thu, 12 Nov 2020 14:04:52 -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; dkim=pass header.i=@kernel.org header.s=default header.b=fT+L4yAa; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727527AbgKLWCa (ORCPT + 99 others); Thu, 12 Nov 2020 17:02:30 -0500 Received: from mail.kernel.org ([198.145.29.99]:49606 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727487AbgKLWC2 (ORCPT ); Thu, 12 Nov 2020 17:02:28 -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 8D0A022241; Thu, 12 Nov 2020 22:02:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605218547; bh=9M4BC2Cr5Q3zI63yXfmamd5rYGuuJOkwMwhYc6Pak7Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fT+L4yAaRwqFS3SOtR6e4aMLNM5+UlpNCByFJPgvZJSGAQcWTfVYSyaamu6gL5/wk YQ9epFVxlUdmQs92fYa+hlwCkIZW8eNFi0h1KSJBwV7wPzkQHn4dmkc07vvPcXZJPj 7J3e3HNAL1a99F1vV+UOw7hwxoY1vPH2dWG3Xc7U= 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, 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 v41 06/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Date: Fri, 13 Nov 2020 00:01:17 +0200 Message-Id: <20201112220135.165028-7-jarkko@kernel.org> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201112220135.165028-1-jarkko@kernel.org> References: <20201112220135.165028-1-jarkko@kernel.org> 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 # v40 # 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