Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp691999ybt; Mon, 6 Jul 2020 20:41:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyU0j6cVLkYGuVPyTN5Hof5aCteOMoEAtsIdkLIgi2arP/vkAJtbByz5CPb4q2BszmCx8En X-Received: by 2002:a17:906:1455:: with SMTP id q21mr29156258ejc.139.1594093309589; Mon, 06 Jul 2020 20:41:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594093309; cv=none; d=google.com; s=arc-20160816; b=ucn8J602G6t4UnxcCkmbAh1x2M1yqrI3L7HxfYlSxB6izoSc+/+F6Rm3FRb+pFBrwR 3tNrKA6ytvQrKIMl9L1+HZnvgdIsjKQIEY0i693HSrmMGJ3Aae8eG6stvfUOx3E4h/RA Yq/1T6vArGvwwkuxpUwhjOeNRhxQhLYzpYjzmjgMp7hvLbvOXSVW0rCMqJrQcqrb0t1f tjT49ASTgxI8NJDIYR13kovrg95DPGzxFgB3pTfSibEqLQGjxeCYGkm3knXVc4c65igF M3tAINUV0cv6y0rOWIDjiHv44gH91OfqSHoFM551G5LZ8NdKGJ0kOsUOWbCK72EgPMoa 001A== 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=azP68oAiXT5Swu/Hyu4OTr5yaQ4WbpqC0YtqC199C1U=; b=nj5pm5BnC+UTUxfGjStONMHNfv1bQzvvoOo9IL5F+32snv+xRQEcQCyZMDhS/IHzsA 5PWrxct2rGU5jKYTlgXX/ess/8+M4ozZ9FAX0TnvJCQlh/Z3/6GVPOM/Jo4SBOek2rwP UFX19WUZRt7MJolTktHU3QBokdF3UzRgXoSHqnMDLb1Eholq3QgeiQNnDF/FYFa9BbjB rX5ANyFrXoB3lbVeFmkN7hvEbNOj8s3j94HCNvn8dl39Rz+S9QqFyT2+Y/T50DrA2xRF VnAOb64hY6uH/HpAxGCIt23N2PaNZ98ZpDejxnnC5j0F8b37VtzY7vFRRGIU4xNclgVu TQtA== 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 j3si14575939edt.8.2020.07.06.20.41.25; Mon, 06 Jul 2020 20:41:49 -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 S1728238AbgGGDii (ORCPT + 99 others); Mon, 6 Jul 2020 23:38:38 -0400 Received: from mga14.intel.com ([192.55.52.115]:28969 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727094AbgGGDii (ORCPT ); Mon, 6 Jul 2020 23:38:38 -0400 IronPort-SDR: F4C7oaRz1a4cMLGoTsmPaOeIW1l1cSYPtLg3hXFv7+urbq+BI9L70JmUOfgHu9DeRgLVEjDD7z Pozfy8b+8rnw== X-IronPort-AV: E=McAfee;i="6000,8403,9674"; a="146609028" X-IronPort-AV: E=Sophos;i="5.75,321,1589266800"; d="scan'208";a="146609028" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2020 20:38:37 -0700 IronPort-SDR: 2NjR3t2ea/FOKojabu1JpuYneXZIc+OGF2G5cme2RcgHsi9eJKestLVScar0iiaWnTLJBNWzXR 4emc1qw6XJhg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,321,1589266800"; d="scan'208";a="427314226" Received: from apiccion-mobl1.ger.corp.intel.com (HELO localhost) ([10.249.45.178]) by orsmga004.jf.intel.com with ESMTP; 06 Jul 2020 20:38:26 -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 v35 03/24] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Date: Tue, 7 Jul 2020 06:37:26 +0300 Message-Id: <20200707033747.142828-4-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20200707033747.142828-1-jarkko.sakkinen@linux.intel.com> References: <20200707033747.142828-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 set 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 to react when this happens (e.g. recreate 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 | 14 ++++++++------ arch/x86/mm/fault.c | 13 +++++++++++++ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/traps.h b/arch/x86/include/asm/traps.h index 714b1a30e7b0..4446f95ad997 100644 --- a/arch/x86/include/asm/traps.h +++ b/arch/x86/include/asm/traps.h @@ -44,12 +44,13 @@ void __noreturn handle_stack_overflow(const char *message, /* * Page fault error code bits: * - * bit 0 == 0: no page found 1: protection fault - * bit 1 == 0: read access 1: write access - * bit 2 == 0: kernel-mode access 1: user-mode access - * bit 3 == 1: use of reserved bit detected - * bit 4 == 1: fault was an instruction fetch - * bit 5 == 1: protection keys block access + * bit 0 == 0: no page found 1: protection fault + * bit 1 == 0: read access 1: write access + * bit 2 == 0: kernel-mode access 1: user-mode access + * bit 3 == 1: use of reserved bit detected + * bit 4 == 1: fault was an instruction fetch + * bit 5 == 1: protection keys block access + * bit 15 == 1: inside SGX enclave */ enum x86_pf_error_code { X86_PF_PROT = 1 << 0, @@ -58,5 +59,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 1ead568c0101..1db6fbd7af8e 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