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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z86-3n1-MArVLM9Z@8bytes.org>
Date: Mon, 10 Mar 2025 11:28:46 +0100
From: Joerg Roedel <joro@...tes.org>
To: "Alexey Gladkov (Intel)" <alexey.gladkov@...el.com>
Cc: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Dave Hansen <dave.hansen@...el.com>, Borislav Petkov <bp@...en8.de>,
	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 Thu, Mar 06, 2025 at 11:37:28AM +0100, Alexey Gladkov (Intel) wrote:
> I was thinking to suggest something like that
> 
> /sys/firmware/coco/tdx/...
> /sys/firmware/coco/sev/...

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).

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.

Is this something we can agree on?

Regards,

	Joerg