Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp1149763pxb; Wed, 6 Apr 2022 09:53:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQS8vfCrvMqoyEZ0p9NY/SyYIohQfyBFtUzzt9NTqPUKOL2kiETQwCVfOtu/ICEoodXUn0 X-Received: by 2002:a17:90b:4ad1:b0:1c7:442c:9ecf with SMTP id mh17-20020a17090b4ad100b001c7442c9ecfmr10752743pjb.240.1649264006673; Wed, 06 Apr 2022 09:53:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649264006; cv=none; d=google.com; s=arc-20160816; b=LZytMVQOiQ+Lc6s3+mBK+skspkflUqGxFSX6y/iyC+FDM/xkvrgh2BimGMcyW+Fhnh VRGIg2bpJkR2W2var14sWmd6AWEQKvNIsKjf1aHJ8g09uUq9Xb7buDTzuRyDT9vwyZJM BKOGcdjotgz0x/WkeoL2LzNeQn3iXqc/wEimbiy1cNhITFLSgwQuVf1igCwsETnsoE15 UKYAyyPanKswZnyOK5EyOdx5Md4qyefZjJnc1k9glM0f6FHY1dMbCSth9Z7DeQhFOZJI FbBDEHxkZrZ5reEmqcSmqBzc/pKGizojYmBDVqgiPxWzTPJfzaDA/37XcHqcvCvBxLe/ y+LA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=YL8GyfSI8y9ebar2tYW4/DPVTaYKS76EdKCf3tbb7u4=; b=Xne2MTTzrfNDiqL4yc90M9I5jwpt9maRWSkJlaKqTfU3mwjwdfhAzzwywiWAf8ZyQC U2LJmGp84Ko8gCN//LHBM1kNfi6CzdNTrFpOGqTTEFrmGYalNYBuJFTW4Me/LU8rrQBU vGSBwM1/PeJI82JXJaXh8ZpdjxuLpaBY+QoyJ7/Y/u3ilbV1zSkvcu1ib+MTFTIk9z2h luo4LdMv0RwL218qgFhwF3xQJtL7udu9Qf1hAgJlBiGArEBN82mXRd9tGal8FWAlxpj3 IMeDUOxpNGgV+KxWakmju9JD3r2VqrZN2l+iovsfkZ0L5CAJGXEFryR4IdgIzdR3UPPp U4dg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gS2G5Tv4; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n12-20020a170902d2cc00b00153b2d16490si16569307plc.152.2022.04.06.09.53.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Apr 2022 09:53:26 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=gS2G5Tv4; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A007829FC69; Wed, 6 Apr 2022 09:06:58 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237239AbiDFQHP (ORCPT + 99 others); Wed, 6 Apr 2022 12:07:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237146AbiDFQG3 (ORCPT ); Wed, 6 Apr 2022 12:06:29 -0400 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E93244DCFE; Tue, 5 Apr 2022 21:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649220594; x=1680756594; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Q3oI3RrMki7HmPelaPOBTibAYke76Zj7jDIb9uCW4Yw=; b=gS2G5Tv4+nSfbp5z4HW1CN4WQ2GrXS66evZ5F/yQLoDUiuKNVnGO/dYA 9yjJr4Yb6rqmMc1AnJXtWYoFg8tsNDGxxh8+I1wu7fndb9QI5W/3GfE7C BXA8Tjr8NRXHjdzeQhe1e7MY3G+vg0zp6LdjHi7zK2ap8hz6GoMbEaTdw EG6VaqKj7v/55oV5Zx9tucE95UmtwvfVHyqdO6EhQ36voZbsZXisUex2R XmF9WY5SX3W/9jqwqLgm4sCbnKzEM8qk9oDEOXAQg9ykR1V3Ydbcbhcei N5aoI0Z91ZhOU41ve3KRl4NbLXKCd72L0sH5E8cajinV0cEyDgtihxsuF A==; X-IronPort-AV: E=McAfee;i="6200,9189,10308"; a="243089771" X-IronPort-AV: E=Sophos;i="5.90,239,1643702400"; d="scan'208";a="243089771" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 21:49:53 -0700 X-IronPort-AV: E=Sophos;i="5.90,239,1643702400"; d="scan'208";a="524302102" Received: from dchang1-mobl3.amr.corp.intel.com (HELO khuang2-desk.gar.corp.intel.com) ([10.254.29.17]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Apr 2022 21:49:49 -0700 From: Kai Huang To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: seanjc@google.com, pbonzini@redhat.com, dave.hansen@intel.com, len.brown@intel.com, tony.luck@intel.com, rafael.j.wysocki@intel.com, reinette.chatre@intel.com, dan.j.williams@intel.com, peterz@infradead.org, ak@linux.intel.com, kirill.shutemov@linux.intel.com, sathyanarayanan.kuppuswamy@linux.intel.com, isaku.yamahata@intel.com, kai.huang@intel.com Subject: [PATCH v3 02/21] x86/virt/tdx: Detect TDX private KeyIDs Date: Wed, 6 Apr 2022 16:49:14 +1200 Message-Id: <2fb62e93734163d2f367fd44e3335cd8a2bf2995.1649219184.git.kai.huang@intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pre-TDX Intel hardware has support for a memory encryption architecture called MKTME. The memory encryption hardware underpinning MKTME is also used for Intel TDX. TDX ends up "stealing" some of the physical address space from the MKTME architecture for crypto-protection to VMs. A new MSR (IA32_MKTME_KEYID_PARTITIONING) helps to enumerate how MKTME- enumerated "KeyID" space is distributed between TDX and legacy MKTME. KeyIDs reserved for TDX are called 'TDX private KeyIDs' or 'TDX KeyIDs' for short. The new MSR is per package and BIOS is responsible for partitioning MKTME KeyIDs and TDX KeyIDs consistently among all packages. Detect TDX private KeyIDs as a preparation to initialize TDX. Similar to detecting SEAMRR, detect on all cpus to detect any potential BIOS misconfiguration among packages. Signed-off-by: Kai Huang --- arch/x86/virt/vmx/tdx/tdx.c | 72 +++++++++++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c index 03f35c75f439..ba2210001ea8 100644 --- a/arch/x86/virt/vmx/tdx/tdx.c +++ b/arch/x86/virt/vmx/tdx/tdx.c @@ -29,9 +29,28 @@ #define SEAMRR_ENABLED_BITS \ (SEAMRR_PHYS_MASK_ENABLED | SEAMRR_PHYS_MASK_LOCKED) +/* + * Intel Trusted Domain CPU Architecture Extension spec: + * + * IA32_MKTME_KEYID_PARTIONING: + * + * Bit [31:0]: number of MKTME KeyIDs. + * Bit [63:32]: number of TDX private KeyIDs. + * + * TDX private KeyIDs start after the last MKTME KeyID. + */ +#define MSR_IA32_MKTME_KEYID_PARTITIONING 0x00000087 + +#define TDX_KEYID_START(_keyid_part) \ + ((u32)(((_keyid_part) & 0xffffffffull) + 1)) +#define TDX_KEYID_NUM(_keyid_part) ((u32)((_keyid_part) >> 32)) + /* BIOS must configure SEAMRR registers for all cores consistently */ static u64 seamrr_base, seamrr_mask; +static u32 tdx_keyid_start; +static u32 tdx_keyid_num; + static bool __seamrr_enabled(void) { return (seamrr_mask & SEAMRR_ENABLED_BITS) == SEAMRR_ENABLED_BITS; @@ -96,7 +115,60 @@ static void detect_seam(struct cpuinfo_x86 *c) detect_seam_ap(c); } +static void detect_tdx_keyids_bsp(struct cpuinfo_x86 *c) +{ + u64 keyid_part; + + /* TDX is built on MKTME, which is based on TME */ + if (!boot_cpu_has(X86_FEATURE_TME)) + return; + + if (rdmsrl_safe(MSR_IA32_MKTME_KEYID_PARTITIONING, &keyid_part)) + return; + + /* If MSR value is 0, TDX is not enabled by BIOS. */ + if (!keyid_part) + return; + + tdx_keyid_num = TDX_KEYID_NUM(keyid_part); + if (!tdx_keyid_num) + return; + + tdx_keyid_start = TDX_KEYID_START(keyid_part); +} + +static void detect_tdx_keyids_ap(struct cpuinfo_x86 *c) +{ + u64 keyid_part; + + /* + * Don't bother to detect this AP if TDX KeyIDs are + * not detected or cleared after earlier detections. + */ + if (!tdx_keyid_num) + return; + + rdmsrl(MSR_IA32_MKTME_KEYID_PARTITIONING, keyid_part); + + if ((tdx_keyid_start == TDX_KEYID_START(keyid_part)) && + (tdx_keyid_num == TDX_KEYID_NUM(keyid_part))) + return; + + pr_err("Inconsistent TDX KeyID configuration among packages by BIOS\n"); + tdx_keyid_start = 0; + tdx_keyid_num = 0; +} + +static void detect_tdx_keyids(struct cpuinfo_x86 *c) +{ + if (c == &boot_cpu_data) + detect_tdx_keyids_bsp(c); + else + detect_tdx_keyids_ap(c); +} + void tdx_detect_cpu(struct cpuinfo_x86 *c) { detect_seam(c); + detect_tdx_keyids(c); } -- 2.35.1