linux-kernel - Re: [PATCH] x86/sev: Make SEV

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: <b0cf4bfc-bf22-4986-9e76-62e3f54179ea@intel.com>
Date: Wed, 5 Mar 2025 08:40:29 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Borislav Petkov <bp@...en8.de>, Joerg Roedel <jroedel@...e.de>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Ingo Molnar <mingo@...nel.org>, Joerg Roedel <joro@...tes.org>,
 x86@...nel.org, hpa@...or.com, Tom Lendacky <thomas.lendacky@....com>,
 Nikunj A Dadhania <nikunj@....com>, linux-kernel@...r.kernel.org,
 Larry.Dewey@....com
Subject: Re: [PATCH] x86/sev: Make SEV_STATUS available via SYSFS

On 3/5/25 07:37, Borislav Petkov wrote:
>> So this question boils down to whether the parsing of the bits happens
>> in kernel- or user-space. Actually there is already parsing in
>> kernel-space to print the status bits into the kernel log:
>>
>> 	SEV: Status: SEV SEV-ES SEV-SNP
>>
>> ... which is great for a quick glance without needing any tools. The
>> user-space tools which already exist have their own parsing of the bits
>> and for them it is much easier to consume the raw value of the
>> SEV_STATUS MSR. See my changes to snpguest:
>>
>> 	https://github.com/virtee/snpguest/pull/88/files
> Well, I guess we can do both:
> 
> cat /sys/...
> 
> SEV_STATUS(0xdeadbeef): SEV SEV-ES SEV-SNP
> 
> So that people don't have to pick apart the MSR hex value.
> 
>> Btw, what is the equivalent on the Intel TDX side for these feature
>> bits?
> There is none, AFAICT. That's why the whole discussion.

TDX's history isn't as exciting as SEV.

TDX guests have CPUID to tell them that they're running that way.

TDX hosts are much more arcane. You can't _actually_ know that it's a
TDX host until you actually start making successful SEAMCALLs and the
TDX module answers them. But we fudge it by just looking at
MSR_IA32_MKTME_KEYID_PARTITIONING at boot and assuming that anything
with that MSR will be able to be a TDX host.

We've just got X86_FEATUREs for hosts and guests:

	#define X86_FEATURE_TDX_HOST_PLATFORM ( 7*32+ 7)
	#define X86_FEATURE_TDX_GUEST ( 8*32+22)

and that's it.

Folks certainly _want_ something in sysfs to dump the TDX module version
and so forth, but we've resisted the urge so far.