linux-kernel - Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption info

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ee9de366-6027-495a-98d9-b8b0cd866bf2@intel.com>
Date:   Thu, 9 Nov 2023 08:50:25 -0800
From:   Dave Hansen <dave.hansen@...el.com>
To:     Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
        linux-kernel@...r.kernel.org,
        Michael Kelley <mhklinux@...look.com>,
        Dexuan Cui <decui@...rosoft.com>
Cc:     linux-hyperv@...r.kernel.org, stefan.bader@...onical.com,
        tim.gardner@...onical.com, roxana.nicolescu@...onical.com,
        cascardo@...onical.com, kys@...rosoft.com, haiyangz@...rosoft.com,
        wei.liu@...nel.org, kirill.shutemov@...ux.intel.com,
        sashal@...nel.org
Subject: Re: [PATCH] x86/mm: Check cc_vendor when printing memory encryption
 info

On 11/9/23 08:35, Jeremi Piotrowski wrote:
> On 09/11/2023 17:25, Dave Hansen wrote:
>> On 11/9/23 08:14, Jeremi Piotrowski wrote:
>> ...
>>>  	pr_info("Memory Encryption Features active:");
>>>  
>>> -	if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
>>> +	if (cc_vendor == CC_VENDOR_INTEL) {
>>>  		pr_cont(" Intel TDX\n");
>>>  		return;
>>>  	}
>>
>> Why aren't these guests setting X86_FEATURE_TDX_GUEST?
> 
> They could if we can confirm that the code gated behind
> cpu_feature_enabled(X86_FEATURE_TDX_GUEST) is correct when running with TD partitioning.

Let me elaborate a bit on my question.

X86_FEATURE_TDX_GUEST is set based on some specific gunk that shows up
in CPUID in TDX guests.  I *believe* it's in one of the CPUID leaves
that the VMM has no control over.

So, first, what in practice is keeping tdx_early_init() from running on
these "TD partitioning" systems?  Because it's either not running, or
I'm misreading the code horribly.

> It still makes sense to have these prints based on the cc_xxx abstractions.

I'm not sure I'm following.

For instance, let's say that someone came up with a nutty reason to do
MKTME in Linux.  We'd need a host-side contraption that sets
CC_ATTR_MEM_ENCRYPT and so forth.  It would also, obviously, set
cc_vendor=CC_VENDOR_INTEL just like host-side SME sets
cc_vendor=CC_VENDOR_AMD.

Then we'd have to go back and disentangle all the places where we
assumed CC_VENDOR_INTEL==TDX.

That, combined with this patch's apparent disregard for why
X86_FEATURE_TDX_GUEST isn't getting set makes me think that the big
picture was not considered here and this patch represents the quickest
hack to get the right spew out to dmesg that is desired.