linux-kernel - Re: [PATCH 2/2] 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: <862e626a-3d4b-40c0-b1b1-6a51b30dcd22@intel.com>
Date: Wed, 12 Mar 2025 09:04:14 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Joerg Roedel <jroedel@...e.de>
Cc: Joerg Roedel <joro@...tes.org>, x86@...nel.org, hpa@...or.com,
 Tom Lendacky <thomas.lendacky@....com>, Nikunj A Dadhania <nikunj@....com>,
 Larry.Dewey@....com, linux-kernel@...r.kernel.org,
 linux-coco@...ts.linux.dev, Juergen Gross <jgross@...e.com>,
 kirill.shutemov@...ux.intel.com, alexey.gladkov@...el.com
Subject: Re: [PATCH 2/2] x86/sev: Make SEV_STATUS available via SYSFS

On 3/12/25 08:07, Joerg Roedel wrote:
> Hi Dave,
> 
> On Wed, Mar 12, 2025 at 07:57:31AM -0700, Dave Hansen wrote:
>> Do we really want to just plumb the raw MSR out to userspace? Users
>> would still need to parse the thing, so it's not _really_ human readable.
> 
> I agree that this is not really human readable. On the other side SYSFS
> is more an interface targeted for tools than optimized for human
> readability (see the one-datum-per-file rule).

Right, but I think it's also intended to be independent and not
*require* tools to make sense of the output. A raw MSR requires tooling
or someone sitting there with the hardware docs to make sense of it.

That's why we have things like:

	/sys/kernel/mm/transparent_hugepage/enabled

that tell you:

	[always] madvise never

as opposed to the old style in:

	/proc/sys/vm/zone_reclaim_mode

which require you to go read the docs and figure out what 0/1/2 mean.

> The actual use-case (and the reason for these patches) of the sev_status
> file is to provide a better and more secure interface than /dev/msr to a
> tool named snpguest.

Let's draw this out to its natural conclusion. There are also a bunch of
TDX attributes that tell you about the capabilities of the VM and the
TDX module.

Should we have:

	/sys/devices/system/cpu/tdx/tdx_attributes

which just dumps out the raw register values that come back from the
TDCALL? Then we'll go write a tdxguest tool to parse those values.