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: <Z9FO1CefzO89syGg@8bytes.org>
Date: Wed, 12 Mar 2025 10:07:32 +0100
From: Joerg Roedel <joro@...tes.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Joerg Roedel <jroedel@...e.de>, Alexey Gladkov <legion@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	Jürgen Groß <jgross@...e.com>,
	"Alexey Gladkov (Intel)" <alexey.gladkov@...el.com>,
	Dave Hansen <dave.hansen@...el.com>, 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 Wed, Mar 12, 2025 at 10:48:37AM +0200, Kirill A. Shutemov wrote:
> There might be a value to have consistent structure for host and guest
> information in sysfs, even if they are presented in different places under
> /sys. There's subset of information that is common for both guest and
> host, like version.

I agree for the host side, but for the guest side I am less convinced.
Any information exposed via sysfs on the guest side can not be trusted.
The only trusted way to get this information in the guest is a
successfully verified attestation report.

The same is true for exposing SEV_STATUS, btw. This can also only be
trusted together with a verified attestation. But the difference is that
SEV_STATUS is not part of the attestation report.

One might say that this does not matter much for debugging purposes, but
the question stands whether it helps the security posture of the TEE to
expose an untrusted interface which tooling then uses instead of the
trusted variant.

Regards,

	Joerg