Received: by 10.213.65.68 with SMTP id h4csp90228imn; Mon, 12 Mar 2018 19:13:14 -0700 (PDT) X-Google-Smtp-Source: AG47ELuD1CgOb5l8W7aGAX+K6j606IKhh3vwVyBgiufONh9V249dE4RXG4hH+4/3Dr5wOmWBdABO X-Received: by 10.98.88.5 with SMTP id m5mr9976977pfb.231.1520907194005; Mon, 12 Mar 2018 19:13:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520907193; cv=none; d=google.com; s=arc-20160816; b=aSpny4/OA9Wd/KmPPe8ghrII296T8MdPzv6VcUD5dtpPtoMsG3MhYYbR8GL/Uu0ZF1 2EOKWZiNqTFoQBC/PqIE2norV+JkiXi9rPoxE6FhoXcU3DBdtHyQRAzFS/T7Wqc+oqTQ GhiBJq3YVo6niU1/5GFP74YsS2HtjdLdJcWoY9p9YbCSMZ3iet1lPn7/ldOYGrE4DEFA F7DuRVfVknRJawa2gAVV1dOlHNjSxdQ6rjHoiBFioFgk+nzMqe1yJdsX9PtyQnKHxAfr uc6wTpvlHwvzm1+Bb7J9VWNKfBP77f7II8IdksgKzcKPh7bAnS/KufGk3cZks3x8JHr4 kAqw== 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:date:to:from:subject:message-id :arc-authentication-results; bh=qiDlDcFQvYLFMx0MSrkMjXJgp/KpqK8+0VqOawt3pyg=; b=T0RJh34phgICZm4IvOkv43UwZdV6ONTin0cjOtRLCOW+RDZPpyvVIW0h9LNfAyYx8p fEgP2OighdPkNvOahsFTrBAsAoTQzdhvV7lVN+iDE+7gad8tCzMDyxOr4VqCK4qcRdxm 7H66a4mqhVx2NpnVDfb9XDJvwYWwqc5Wu7dKHrzuwZayTUCH81xP5kApWeW79Jr37+KT W2S/0r4Ek6EKPU5LVpIIP75KyJX9/iS4lyZWjXShVWnRQemXf8eJzIcrg9fp8u2OeBwl QHb38+oyKDEnvEKBdP0L5AtOqB4aev4jEx+3b2uN2fdLG/VrU3OoY+6U+LAPbXclleFl KuaQ== 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 t71si5924124pgc.793.2018.03.12.19.12.59; Mon, 12 Mar 2018 19:13:13 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932434AbeCMCMH (ORCPT + 99 others); Mon, 12 Mar 2018 22:12:07 -0400 Received: from mga12.intel.com ([192.55.52.136]:19430 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751462AbeCMCMF (ORCPT ); Mon, 12 Mar 2018 22:12:05 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2018 19:12:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,463,1515484800"; d="scan'208";a="33307008" Received: from khuang2-desk.gar.corp.intel.com ([10.254.16.24]) by FMSMGA003.fm.intel.com with ESMTP; 12 Mar 2018 19:12:03 -0700 Message-ID: <1520907122.6421.8.camel@linux.intel.com> Subject: Re: [tip:x86/mm] x86/tme: Detect if TME and MKTME is activated by BIOS From: Kai Huang To: dave.hansen@intel.com, peterz@infradead.org, hpa@zytor.com, mingo@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, kirill.shutemov@linux.intel.com, thomas.lendacky@amd.com, linux-tip-commits@vger.kernel.org Date: Tue, 13 Mar 2018 15:12:02 +1300 In-Reply-To: References: <20180305162610.37510-3-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-03-12 at 05:21 -0700, tip-bot for Kirill A. Shutemov wrote: > Commit-ID: cb06d8e3d020c30fe10ae711c925a5319ab82c88 > Gitweb: https://git.kernel.org/tip/cb06d8e3d020c30fe10ae711c925a5 > 319ab82c88 > Author: Kirill A. Shutemov > AuthorDate: Mon, 5 Mar 2018 19:25:50 +0300 > Committer: Ingo Molnar > CommitDate: Mon, 12 Mar 2018 12:10:54 +0100 > > x86/tme: Detect if TME and MKTME is activated by BIOS > > 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 > Cc: Dave Hansen > Cc: Kai Huang > Cc: Linus Torvalds > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Tom Lendacky > Cc: linux-mm@kvack.org > Link: http://lkml.kernel.org/r/20180305162610.37510-3-kirill.shutemov > @linux.intel.com > Signed-off-by: Ingo Molnar > --- > 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 4aa9fd379390..b862067bb33c 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -510,6 +510,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; It seems setup_pku() will call get_cpu_cap to restore c->x86_phys_bits later? In which case I think you need to change setup_pku as well. And for the comments here, I think it can be refined. It is true that VM guest needs to know bits of physical address, but this info is not used only by VM. I think the reason we need to update is this is simply the fact. Thanks, -Kai > +} > + > static void init_intel_energy_perf(struct cpuinfo_x86 *c) > { > u64 epb; > @@ -680,6 +767,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);