Re: [PATCH] x86/sev: Make SEV_STATUS available via SYSFS

Dave Hansen
2025-03-05T16:40:09Z

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.