From patchwork Wed May 8 14:44:14 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "kirill.shutemov@linux.intel.com" X-Patchwork-Id: 10935937 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BE70F15A6 for ; Wed, 8 May 2019 14:47:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AD5F028485 for ; Wed, 8 May 2019 14:47:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A145728958; Wed, 8 May 2019 14:47:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=unavailable version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 46AB228485 for ; Wed, 8 May 2019 14:47:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726736AbfEHOrS (ORCPT ); Wed, 8 May 2019 10:47:18 -0400 Received: from mga03.intel.com ([134.134.136.65]:59536 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728474AbfEHOow (ORCPT ); Wed, 8 May 2019 10:44:52 -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 orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2019 07:44:51 -0700 X-ExtLoop1: 1 Received: from black.fi.intel.com ([10.237.72.28]) by orsmga005.jf.intel.com with ESMTP; 08 May 2019 07:44:46 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 672C3116A; Wed, 8 May 2019 17:44:31 +0300 (EEST) From: "Kirill A. Shutemov" To: Andrew Morton , x86@kernel.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Peter Zijlstra , Andy Lutomirski , David Howells Cc: Kees Cook , Dave Hansen , Kai Huang , Jacob Pan , Alison Schofield , linux-mm@kvack.org, kvm@vger.kernel.org, keyrings@vger.kernel.org, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: [PATCH, RFC 54/62] x86/mm: Disable MKTME on incompatible platform configurations Date: Wed, 8 May 2019 17:44:14 +0300 Message-Id: <20190508144422.13171-55-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> References: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Sender: kvm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Icelake Server requires additional check to make sure that MKTME usage is safe on Linux. Kernel needs a way to access encrypted memory. There can be different approaches to this: create a temporary mapping to access the page (using kmap() interface), modify kernel's direct mapping on allocation of encrypted page. In order to minimize runtime overhead, the Linux MKTME implementation uses multiple direct mappings, one per-KeyID. Kernel uses the direct mapping that is relevant for the page at the moment. Icelake Server in some configurations doesn't allow a page to be mapped with multiple KeyIDs at the same time. Even if only one of KeyIDs is actively used. It conflicts with the Linux MKTME implementation. OS can check if it's safe to map the same with multiple KeyIDs by examining bit 8 of MSR 0x6F. If the bit is set we cannot safely use MKTME on Linux. The user can disable the Directory Mode in BIOS setup to get the platform into Linux-compatible mode. Signed-off-by: Kirill A. Shutemov --- arch/x86/include/asm/intel-family.h | 2 ++ arch/x86/kernel/cpu/intel.c | 22 ++++++++++++++++++++++ 2 files changed, 24 insertions(+) diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h index 9f15384c504a..6a633af144aa 100644 --- a/arch/x86/include/asm/intel-family.h +++ b/arch/x86/include/asm/intel-family.h @@ -53,6 +53,8 @@ #define INTEL_FAM6_CANNONLAKE_MOBILE 0x66 #define INTEL_FAM6_ICELAKE_MOBILE 0x7E +#define INTEL_FAM6_ICELAKE_X 0x6A +#define INTEL_FAM6_ICELAKE_XEON_D 0x6C /* "Small Core" Processors (Atom) */ diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index f402a74c00a1..3fc318f699d3 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -19,6 +19,7 @@ #include #include #include +#include #ifdef CONFIG_X86_64 #include @@ -531,6 +532,16 @@ static void detect_vmx_virtcap(struct cpuinfo_x86 *c) #define TME_ACTIVATE_CRYPTO_ALGS(x) ((x >> 48) & 0xffff) /* Bits 63:48 */ #define TME_ACTIVATE_CRYPTO_AES_XTS_128 1 +#define MSR_ICX_MKTME_STATUS 0x6F +#define MKTME_ALIASES_FORBIDDEN(x) (x & BIT(8)) + +/* Need to check MSR_ICX_MKTME_STATUS for these CPUs */ +static const struct x86_cpu_id mktme_status_msr_ids[] = { + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ICELAKE_X }, + { X86_VENDOR_INTEL, 6, INTEL_FAM6_ICELAKE_XEON_D }, + {} +}; + /* Values for mktme_status (SW only construct) */ #define MKTME_ENABLED 0 #define MKTME_DISABLED 1 @@ -564,6 +575,17 @@ static void detect_tme(struct cpuinfo_x86 *c) return; } + /* Icelake Server quirk: do not enable MKTME if aliases are forbidden */ + if (x86_match_cpu(mktme_status_msr_ids)) { + u64 mktme_status; + rdmsrl(MSR_ICX_MKTME_STATUS, mktme_status); + + if (MKTME_ALIASES_FORBIDDEN(mktme_status)) { + pr_err_once("x86/tme: Directory Mode is enabled in BIOS\n"); + mktme_status = MKTME_DISABLED; + } + } + if (mktme_status != MKTME_UNINITIALIZED) goto detect_keyid_bits;