Received: by 10.223.185.116 with SMTP id b49csp2778286wrg; Mon, 5 Mar 2018 08:32:23 -0800 (PST) X-Google-Smtp-Source: AG47ELvbtXKTxSNN1kwQ1QEfu/PYPW7ObjZTRa0uOkyaPUSpwMDQjJ6GKgTPJwTzHtPdto03aXyy X-Received: by 10.99.96.206 with SMTP id u197mr12223932pgb.261.1520267543596; Mon, 05 Mar 2018 08:32:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520267543; cv=none; d=google.com; s=arc-20160816; b=XBQSPAe6SRmyezP2yyrPh2+bead2A/eqJur4LIUl/xF+LDczJV1jj+3JtC5aZyvSuj rTNiVfy/DI/KvKmJk+bNIXe264gGTSwbPrNf4YL/rLucYvfF3uSYdADX0JlgfLd4DWzd mG5FY3NfbFj5AYaegmhfSPybDCajuwszLBl2O0MFzw5FECTfUBsyZNo9zvysID4NugVO rIxIcpuZUdy3KA47tpEFZqxQcayud3mU5A3Dg/qb1PzFhUbvTOuXc9i0flVi6CHu02Rl vduAIgChQSOSG8dIkmkk6bKfA+B1TSvxfmQa8vhARjZ9Li6QOmxYmKJA7CQmWZ1BAh/0 731w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=klZHqRghyrkeD8mUNmp4m/PPYCOHqvBHWXBH0+5GD/M=; b=MYWdpwGEL6046N820CfTAchuGa0t+sWGhXMS74avNwv/DdJmFB8w2b+nbddfT0ALVX s2CDEu4d00ouN0/CBZhn7Mm1UGaLmwjFVd/dXwWSZ8YOBHMHmHwAya361ahMn3YycsGg s5XmFUk42+bdn7fQ6To6Y0e5gGyno4cM6hj80BFsQuBX9/UXp8HGRn4TNg4cyxlUHMsX a+LbJp1Zm5Dcc+c50/SQB7VPrdmxLoxCN3maBOLXKVK3KRFC1lj34/3A7B+rkb3TpBg/ tX+8rxxG9AFSR7jYGXJlJISxM7WTDFccjLxtqg9tLp7Pd6pCCohhaZ4nSoPkDo6mioJW f20A== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p23-v6si2200526plo.275.2018.03.05.08.32.09; Mon, 05 Mar 2018 08:32:23 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752586AbeCEQ0a (ORCPT + 99 others); Mon, 5 Mar 2018 11:26:30 -0500 Received: from mga04.intel.com ([192.55.52.120]:44459 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbeCEQ0X (ORCPT ); Mon, 5 Mar 2018 11:26:23 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2018 08:26:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,427,1515484800"; d="scan'208";a="21956949" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga007.fm.intel.com with ESMTP; 05 Mar 2018 08:26:20 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id E49A92BB; Mon, 5 Mar 2018 18:26:19 +0200 (EET) From: "Kirill A. Shutemov" To: Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky Cc: Dave Hansen , Kai Huang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Kirill A. Shutemov" Subject: [RFC, PATCH 02/22] x86/tme: Detect if TME and MKTME is activated by BIOS Date: Mon, 5 Mar 2018 19:25:50 +0300 Message-Id: <20180305162610.37510-3-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180305162610.37510-1-kirill.shutemov@linux.intel.com> References: <20180305162610.37510-1-kirill.shutemov@linux.intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org IA32_TME_ACTIVATE MSR (0x982) can be used to check if BIOS has enabled TME and MKTME. It includes which encryption policy/algorithm is selected for TME or available for MKTME. For MKTME, the MSR also enumerates how many KeyIDs are available. We would need to exclude KeyID bits from physical address bits. detect_tme() would adjust cpuinfo_x86::x86_phys_bits accordingly. We have to do this even if we are not going to use KeyID bits ourself. VM guests still have to know that these bits are not usable for physical address. Signed-off-by: Kirill A. Shutemov --- arch/x86/kernel/cpu/intel.c | 90 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c index d19e903214b4..c770689490b5 100644 --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -503,6 +503,93 @@ static void detect_vmx_virtcap(struct cpuinfo_x86 *c) } } +#define MSR_IA32_TME_ACTIVATE 0x982 + +/* Helpers to access TME_ACTIVATE MSR */ +#define TME_ACTIVATE_LOCKED(x) (x & 0x1) +#define TME_ACTIVATE_ENABLED(x) (x & 0x2) + +#define TME_ACTIVATE_POLICY(x) ((x >> 4) & 0xf) /* Bits 7:4 */ +#define TME_ACTIVATE_POLICY_AES_XTS_128 0 + +#define TME_ACTIVATE_KEYID_BITS(x) ((x >> 32) & 0xf) /* Bits 35:32 */ + +#define TME_ACTIVATE_CRYPTO_ALGS(x) ((x >> 48) & 0xffff) /* Bits 63:48 */ +#define TME_ACTIVATE_CRYPTO_AES_XTS_128 1 + +/* Values for mktme_status (SW only construct) */ +#define MKTME_ENABLED 0 +#define MKTME_DISABLED 1 +#define MKTME_UNINITIALIZED 2 +static int mktme_status = MKTME_UNINITIALIZED; + +static void detect_tme(struct cpuinfo_x86 *c) +{ + u64 tme_activate, tme_policy, tme_crypto_algs; + int keyid_bits = 0, nr_keyids = 0; + static u64 tme_activate_cpu0 = 0; + + rdmsrl(MSR_IA32_TME_ACTIVATE, tme_activate); + + if (mktme_status != MKTME_UNINITIALIZED) { + if (tme_activate != tme_activate_cpu0) { + /* Broken BIOS? */ + pr_err_once("x86/tme: configuation is inconsistent between CPUs\n"); + pr_err_once("x86/tme: MKTME is not usable\n"); + mktme_status = MKTME_DISABLED; + + /* Proceed. We may need to exclude bits from x86_phys_bits. */ + } + } else { + tme_activate_cpu0 = tme_activate; + } + + if (!TME_ACTIVATE_LOCKED(tme_activate) || !TME_ACTIVATE_ENABLED(tme_activate)) { + pr_info_once("x86/tme: not enabled by BIOS\n"); + mktme_status = MKTME_DISABLED; + return; + } + + if (mktme_status != MKTME_UNINITIALIZED) + goto detect_keyid_bits; + + pr_info("x86/tme: enabled by BIOS\n"); + + tme_policy = TME_ACTIVATE_POLICY(tme_activate); + if (tme_policy != TME_ACTIVATE_POLICY_AES_XTS_128) + pr_warn("x86/tme: Unknown policy is active: %#llx\n", tme_policy); + + tme_crypto_algs = TME_ACTIVATE_CRYPTO_ALGS(tme_activate); + if (!(tme_crypto_algs & TME_ACTIVATE_CRYPTO_AES_XTS_128)) { + pr_err("x86/mktme: No known encryption algorithm is supported: %#llx\n", + tme_crypto_algs); + mktme_status = MKTME_DISABLED; + } +detect_keyid_bits: + keyid_bits = TME_ACTIVATE_KEYID_BITS(tme_activate); + nr_keyids = (1UL << keyid_bits) - 1; + if (nr_keyids) { + pr_info_once("x86/mktme: enabled by BIOS\n"); + pr_info_once("x86/mktme: %d KeyIDs available\n", nr_keyids); + } else { + pr_info_once("x86/mktme: disabled by BIOS\n"); + } + + if (mktme_status == MKTME_UNINITIALIZED) { + /* MKTME is usable */ + mktme_status = MKTME_ENABLED; + } + + /* + * Exclude KeyID bits from physical address bits. + * + * We have to do this even if we are not going to use KeyID bits + * ourself. VM guests still have to know that these bits are not usable + * for physical address. + */ + c->x86_phys_bits -= keyid_bits; +} + static void init_intel_energy_perf(struct cpuinfo_x86 *c) { u64 epb; @@ -673,6 +760,9 @@ static void init_intel(struct cpuinfo_x86 *c) if (cpu_has(c, X86_FEATURE_VMX)) detect_vmx_virtcap(c); + if (cpu_has(c, X86_FEATURE_TME)) + detect_tme(c); + init_intel_energy_perf(c); init_intel_misc_features(c); -- 2.16.1