Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2690745imd; Fri, 2 Nov 2018 16:16:28 -0700 (PDT) X-Google-Smtp-Source: AJdET5dWdml7sQNVqoZFPK0Y1ImmezpTMvlAnzCxsyFArVAd9HdyFnmOCs88D7bzbbFXfdN7RJ4P X-Received: by 2002:a17:902:1124:: with SMTP id d33-v6mr13923286pla.125.1541200588791; Fri, 02 Nov 2018 16:16:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541200588; cv=none; d=google.com; s=arc-20160816; b=psfjvPxQmQpA9mM+QjPbLWt2TNAmyvbyEo0Jv1Nv4vkQw6sWnzp/YO9egs/PwKuGQu rvgJeYiN1W07OdBNMfs6Q5aNJTAsEYA9imBbdFRo25ZGpbFHt8E8Uy69PvFoqhlur9aR vAxmoNgcNg8mwSr2yx9X1TB5fkM8eKC4zMEF+t2iDAFYPjxH3WG3/lg12lTl1WO6gj0O ty+Lf9si8X7+reVf0SHrwmcvX/H9uu2UXZC7LXMH1bpXfFeACH6Qd/YkuhMa0NlffjSM /rwLyTcZbK28pUSxN5U24ciObsUZ5iVw8zC3vfjQXsb+qLgd5cwnOkqMOOc2K0MTY3zu mDEg== 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; bh=CVtoGokp/Og8C4u8qwTwkLkv5tNnTgi6/mQdlHzi3/g=; b=X5jE7+VqHn07WqUCfo26gBYhrXOVvX0jnV0Ne62twgwZFuGvO22mEYmsLOQQRNj6tv ZSO3ICMD+xk7nLiF5LbhYwHlR9ycUii1vQ9i2CzOEDRWIsBhwdy7Ha3Vh/xQc7jBrq1Y rtcFzDtQvaQtOnuLRut6tCqoOHn1u71fjXRVPQkuozer122kA7osuLRqg142IP5uQSEq DwFf+8gQfbVII570RWmBtEuwfq16MfQdGhU0scbT1NVKmxe1IYY3Sg/0JLYmlG3seQ2M 68iXa7kymPW1HH+hOS16FW9wW4EtM7HcFrM+/W3hlP3WKkggnz3BVFY1cmMCj05B853q bGeA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id o2-v6si36072810pgj.111.2018.11.02.16.16.14; Fri, 02 Nov 2018 16:16:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1728622AbeKCIYX (ORCPT + 99 others); Sat, 3 Nov 2018 04:24:23 -0400 Received: from mga14.intel.com ([192.55.52.115]:32437 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728230AbeKCIYX (ORCPT ); Sat, 3 Nov 2018 04:24:23 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 16:15:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,457,1534834800"; d="scan'208";a="270987832" Received: from btyborox-mobl.ger.corp.intel.com (HELO localhost) ([10.249.254.138]) by orsmga005.jf.intel.com with ESMTP; 02 Nov 2018 16:15:06 -0700 From: Jarkko Sakkinen To: x86@kernel.org, platform-driver-x86@vger.kernel.org, linux-sgx@vger.kernel.org Cc: dave.hansen@intel.com, sean.j.christopherson@intel.com, nhorman@redhat.com, npmccallum@redhat.com, serge.ayoun@intel.com, shay.katz-zamir@intel.com, haitao.huang@intel.com, mark.shanahan@intel.com, andriy.shevchenko@linux.intel.com, Andy Lutomirski , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , linux-kernel@vger.kernel.org (open list:X86 MM) Subject: [PATCH v15 07/23] x86/mm: x86/sgx: Signal SIGSEGV for userspace #PFs w/ PF_SGX Date: Sat, 3 Nov 2018 01:11:06 +0200 Message-Id: <20181102231320.29164-8-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.19.1 In-Reply-To: <20181102231320.29164-1-jarkko.sakkinen@linux.intel.com> References: <20181102231320.29164-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 The PF_SGX bit is set if and only if the #PF is detected by the SGX Enclave Page Cache Map (EPCM). The EPCM is a hardware-managed table that enforces accesses to an enclave's EPC pages in addition to the software-managed kernel page tables, i.e. the effective permissions for an EPC page are a logical AND of the kernel's page tables and the corresponding EPCM entry. The EPCM is consulted only after an access walks the kernel's page tables, i.e.: a. the access was allowed by the kernel b. the kernel's tables have become less restrictive than the EPCM c. the kernel cannot fixup the cause of the fault Noteably, (b) implies that either the kernel has botched the EPC mappings or the EPCM has been invalidated (see below). Regardless of why the fault occurred, userspace needs to be alerted so that it can take appropriate action, e.g. restart the enclave. This is reinforced by (c) as the kernel doesn't really have any other reasonable option, i.e. signalling SIGSEGV is actually the least severe action possible. Although the primary purpose of the EPCM is to prevent a malicious or compromised kernel from attacking an enclave, e.g. by modifying the enclave's page tables, do not WARN on a #PF w/ PF_SGX set. The SGX architecture effectively allows the CPU to invalidate all EPCM entries at will and requires that software be prepared to handle an EPCM fault at any time. The architecture defines this behavior because the EPCM is encrypted with an ephemeral key that isn't exposed to software. As such, the EPCM entries cannot be preserved across transitions that result in a new key being used, e.g. CPU power down as part of an S3 transition or when a VM is live migrated to a new physical system. Cc: Andy Lutomirski Cc: Dave Hansen Signed-off-by: Sean Christopherson --- arch/x86/mm/fault.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 47bebfe6efa7..11d16bcf6e64 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -1153,6 +1153,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, e.g. 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.19.1