Received: by 10.223.176.5 with SMTP id f5csp365997wra; Wed, 7 Feb 2018 00:17:26 -0800 (PST) X-Google-Smtp-Source: AH8x224vCy2jel+K8o9sLUjzsDI8cPwxYJMdGQ/b2hdlB14EYI9nxqDwki1Vhb/nwYV5QZBIXV2O X-Received: by 10.99.114.90 with SMTP id c26mr4241281pgn.427.1517991445941; Wed, 07 Feb 2018 00:17:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517991445; cv=none; d=google.com; s=arc-20160816; b=trcjlthfKl7GytLDwFRqa7hZw0xGz3TBcUXnrRJIoSbS28X987IsUMHuJI5YzIaavu FLjm72Sc4gr0Qti3mfLZGxjrBHl5H09JoG9GQwUtORFzGIK4onGKHbJjEAWGEG5ZA94Z gQ0cBkl8aCct3m8w8FwMPdHnrwoNZLxRHzHaAYwQeksrTDuwcypZCUi8ZGmAKmDkTDZx xlfpKrxoIZSKTte7HW/b6pgKz3Ubjkw+BVcL0zeTtdIlG+mMWhMyrU0hxKghAJ9Wj+w2 jsCbwaFcLR87tZ8FeDwF8HIvW+kV1fXfK0QJP1lwjPJduGuYKtqP+Da7LeIYEc8MrNU+ dxmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=W9agUf2kkv2dLpdWO+plqZFIrGtPcHg9JF5yFsIck7g=; b=B+acHysI9/VKQ6zOg5xiEQO37S9gdChELjlIC2Va5tVNm4Oo1v1k1eBOBZmaxTferr gX+gSS5f9vNBCcSo7OmievTB3Mvhm5ZcK4avmHDoeaGu1uGszBCj2twmMBaaWtyms0IL gGxikizAg3uvZ8RMVXZd+I7GXIXSCQlSvudoB+HMuD5a9SEpKXWZnxmArhZmvga2x2p1 YVmLJK1Fa1TfuKGp0oFkEGpvXU6eyqQ3AE1vH8FT76we9WSUIIOZ2Hzub4LSDFGT+RaX U1wAMN8gMTpRehKx4PetYNzi4g3XF3UpSCS7Ml58c3w16mXaurD+OI3rUDWhDnbTLyfl cf8g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Lf3SxOgK; 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 62-v6si709681ply.651.2018.02.07.00.17.10; Wed, 07 Feb 2018 00:17:25 -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; dkim=pass header.i=@shutemov-name.20150623.gappssmtp.com header.s=20150623 header.b=Lf3SxOgK; 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 S1753363AbeBGIQb (ORCPT + 99 others); Wed, 7 Feb 2018 03:16:31 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:50379 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750815AbeBGIQa (ORCPT ); Wed, 7 Feb 2018 03:16:30 -0500 Received: by mail-wm0-f65.google.com with SMTP id f71so1417913wmf.0 for ; Wed, 07 Feb 2018 00:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shutemov-name.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=W9agUf2kkv2dLpdWO+plqZFIrGtPcHg9JF5yFsIck7g=; b=Lf3SxOgKeMeeNdOy6WW/rENb1n9Kk++NLKWnjRsLBUpyaJOw4rNEX1TGoJAhkA2vk5 ILlz0FDcQ/lcoCoAKISe2XKCP/qcP02bqLRfA0Ek3Y6gyGbziNqqsLmDUrVGEEHLe8Wv yBmuTvGnGJfRo9zEwNzISWxSUw2my+AZyZq6X2U8zaFEMCp9IWL8h4D0IIaE2X7r2H3m XcXwemiklfWFcQnNE4SXEtNpjWNjOoQFEHzxecaqZM6qh/Z++uuEj5s94YE+4V7+2OsZ gDZi8n1MaHaFL8BFqJVZbJlI0+oYGw6J1bp/zhE3j50C0uIUxfN9s65hTUS7rZnVyblb HsJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=W9agUf2kkv2dLpdWO+plqZFIrGtPcHg9JF5yFsIck7g=; b=AZMNhipIV/YVdjo+SRuOmMzCJMzM1UYLTG6hpozzaMu3bfBUXTWD8NmAL+JltuyuCj /wCmxFRnVbuXn9cMchzMfJmcsfmbIdjYMADFl/cp+DpY0uPLlAzmihGl0JeKkiiePAof v0snAxXAmX8MDNINxHot9LehzhQypys07WZccJCn0UiEcxn2yqS7xxJVj5kBoBO4YjDB BeVZhTf37ho3gJKGB++9ULB4HaYqc2JZAUgp8wM+ynYJEapFRAjdGn/OrKmVUKmHwkNc UtSJTj/i8QURRT7RCG6lWhr3jI46JYazPcRpw92u+tyoQvsncy+9JYrrQRZncwnP16Ti Ebsw== X-Gm-Message-State: APf1xPCQT0vG91RHzMGrnTmONTyYQaUHSxBZgHrWojA/InE8UX8aJzw/ SdNvd/lQ4ognUdYY8YhGJEnIBA== X-Received: by 10.80.145.115 with SMTP id f48mr7208497eda.92.1517991389139; Wed, 07 Feb 2018 00:16:29 -0800 (PST) Received: from node.shutemov.name ([178.121.192.223]) by smtp.gmail.com with ESMTPSA id 15sm886805eds.54.2018.02.07.00.16.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 00:16:28 -0800 (PST) Received: by node.shutemov.name (Postfix, from userid 1000) id 2EB27648D520; Wed, 7 Feb 2018 11:16:27 +0300 (+03) Date: Wed, 7 Feb 2018 11:16:27 +0300 From: "Kirill A. Shutemov" To: Kai Huang Cc: "Kirill A. Shutemov" , Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky , Dave Hansen , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] x86/tme: Detect if TME and MKTME is activated by BIOS Message-ID: <20180207081627.eomxuyqw74eew756@node.shutemov.name> References: <20180131091509.26531-1-kirill.shutemov@linux.intel.com> <20180131091509.26531-3-kirill.shutemov@linux.intel.com> <1517978050.23889.23.camel@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1517978050.23889.23.camel@linux.intel.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 07, 2018 at 05:34:10PM +1300, Kai Huang wrote: > On Wed, 2018-01-31 at 12:15 +0300, Kirill A. Shutemov wrote: > > 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. > > > > Signed-off-by: Kirill A. Shutemov > > --- > > arch/x86/kernel/cpu/intel.c | 83 > > +++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 83 insertions(+) > > > > diff --git a/arch/x86/kernel/cpu/intel.c > > b/arch/x86/kernel/cpu/intel.c > > index 6936d14d4c77..5b95fa484837 100644 > > --- a/arch/x86/kernel/cpu/intel.c > > +++ b/arch/x86/kernel/cpu/intel.c > > @@ -517,6 +517,86 @@ static void detect_vmx_virtcap(struct > > cpuinfo_x86 *c) > > } > > } > > > > +#define MSR_IA32_TME_ACTIVATE 0x982 > > Should this MSR go into msr-index.h? No. Comment from msr-index.h: * Do not add new entries to this file unless the definitions are shared * between multiple compilation units. > > + > > +#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 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 1 > > + > > +#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) { > > + /* Broken BIOS? */ > > + if (tme_activate != tme_activate_cpu0) { > > + pr_err_once("TME: configuation is > > inconsistent between CPUs\n"); > > + mktme_status = MKTME_DISABLED; > > + } > > + goto out; > > Why goto out here? If something goes wrong, I think it is pointless to > read keyID bits staff? IMHO if something goes wrong, you should set > mktme_status to disabled, and clear tme_activate_cpu0? We still have to mask out keyid bits from x86_phys_bits if CPU has TME enabled. But yeah, as you pointed below, I need to check that it actually locked and enabled. > > + } > > + > > + tme_activate_cpu0 = tme_activate; > > + > > + if (!TME_ACTIVATE_LOCKED(tme_activate) || > > !TME_ACTIVATE_ENABLED(tme_activate)) { > > + pr_info("TME: not enabled by BIOS\n"); > > + mktme_status = MKTME_DISABLED; > > + goto out; > > I think it is pointless to read keyID bits staff if TME is not even > enabled. > > > + } > > + > > + pr_info("TME: enabled by BIOS\n"); > > + > > + tme_policy = TME_ACTIVATE_POLICY(tme_activate); > > + if (tme_policy != TME_ACTIVATE_POLICY_AES_XTS) > > + pr_warn("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)) { > > + pr_err("MKTME: No known encryption algorithm is > > supported: %#llx\n", > > + tme_crypto_algs); > > + mktme_status = MKTME_DISABLED; > > + } > > To me it is a little bit confusing about the naming. tme_policy is the > crypto_alg used by TME keyID (0), and tme_crypto_algs is bitmap of > supported crypto_algs for MK-TME. Probably a better naming is needed? > And the naming of TME_ACTIVATE_POLICY(x), TME_ACTIVATE_CRYPTO_ALGS(x) > above as well? Suggestions? -- Kirill A. Shutemov