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: <2eopafgnsx7pktqfqhu2nye44ib7ifz2cppqt7gunrltpxrnj6@i7jwe6jrun73>
Date: Wed, 12 Mar 2025 12:59:50 +0200
From: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
To: Joerg Roedel <joro@...tes.org>
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:07:32AM +0100, Joerg Roedel wrote:
> 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.

I am not sure I understand your point.

In TDX case it is as trusted as the kernel itself. If the system is
attested, this info is going to accurate too as kernel gets information
from trusted TDX module.

But nobody suggested to use this information to judge the security of the
system.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov