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: <20250310110202.GEZ87GqgEJyhJtde0I@fat_crate.local>
Date: Mon, 10 Mar 2025 12:02:02 +0100
From: Borislav Petkov <bp@...en8.de>
To: Joerg Roedel <joro@...tes.org>
Cc: "Alexey Gladkov (Intel)" <alexey.gladkov@...el.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...el.com>, Joerg Roedel <jroedel@...e.de>,
	Ingo Molnar <mingo@...nel.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 Mon, Mar 10, 2025 at 11:28:46AM +0100, Joerg Roedel wrote:
> So on a second thought I'd like to vote for the /sys/hypervisor/
> hierarchy. The `firmware` term is a bit amibious here, the TDX module
> can be seen as a kind of firmware for the guest OS, but realistically it
> is more like another hypervisor sitting between KVM and the guest.
> 
> Also the settings on the SEV side that need to be exposed (VMPL and
> SEV_STATUS) are CPU properties, but on the other side also set by some
> form of hypervisor (either KVM/QEMU, the SVSM, or some other paravisor
> in-between).

Dunno, it still reads weird because if you wanna put guest-specific things in
there, /sys/hypervisor really sounds like the wrong place...

> Overall /sys/hypervisor/ seems to be the best-fitting location for all
> this data. To avoid ambiguation I propose:
> 
> 	/sys/hypervisor/common/[coco/]tdx/
> 	/sys/hypervisor/common/[coco/]sev/
> 
> Using `common` makes it clear that this directory does not point to some
> sort of Hypervisor, but to data common to all hypervisors. Using another
> `coco` subdirectory is not necessary in my view, but if people think it
> should exist I am fine with that.

... or you can drop the "common" thing and use only the "coco":

/sys/hypervisor/coco

and then you kinda denote that while it is the hypervisor hierarchy, it is
related to confidential computing so it could be consumed by guests too.

But I still don't see why we can't simply do

/sys/guest

It is just another sysfs node. Or is there a particular reason to stick to
/sys/hypervisor?

And putting it in sysfs still doesn't solve the human-readable aspect: dumping
a raw SEV_STATUS might as well be simply reading the MSR and if someone wants
to read it, someone would need to go count bits. Imagine the following
scenario: a user reports a bug, you say, ok, send me

/sys/hypervisor/coco/sev/sev_status

you get it and you dump it through your script or start looking at the bits.
Yeah, we all have scripts for that but it ain't too user-friendly...

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette