linux-kernel - Re: "Paravisor" Feature Enumeration

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: <4ed7bbb991de771e68d435ff5aca929f20616295.camel@intel.com>
Date: Tue, 6 Jan 2026 19:17:21 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, "Lange, Jon"
	<jlange@...rosoft.com>, "andrew.cooper3@...rix.com"
	<andrew.cooper3@...rix.com>
CC: "seanjc@...gle.com" <seanjc@...gle.com>, "mark.rutland@....com"
	<mark.rutland@....com>, "john.starks@...rosoft.com"
	<john.starks@...rosoft.com>, "Williams, Dan J" <dan.j.williams@...el.com>,
	"will@...nel.org" <will@...nel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "linux-coco@...ts.linux.dev"
	<linux-coco@...ts.linux.dev>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "kirill.shutemov@...ux.intel.com"
	<kirill.shutemov@...ux.intel.com>
Subject: Re: "Paravisor" Feature Enumeration

On Tue, 2026-01-06 at 01:44 +0000, Andrew Cooper wrote:
> I agree that it seems like "just" an enumeration problem, but despite
> attending the presentation and rereading the slides, I'm still not clear
> on the precise scope.
> 
> Are we saying that, inside an opaque blob that a customer provides to a
> CSP to run we might have:
> 
> * a paravisor and an unaware OS, or
> * svsm and a fully-aware OS, or
> * something in-between these two.
> 
> and we're looking a way to describe which piece of the interior stack
> owns which capability/service?
> 
> If so, it can't come in from the outside; given that it's the capability
> enumeration, there's a chicken/egg problem with verifying the integrity.
> 
> It seems like it needs to be produced by whatever the first code to run
> is, after gathering capabilities in a vendor-specific way, and deciding
> which services it wants to provide, and which to delegate.
> 
> And if so, then it definitely cannot be in CPUID because that needs to
> be fixed from prior to the guest starting to run, and doesn't express
> dynamic properties of the system[*]

For TDX, the guest has some control of the CPUID bits. Both via #VE
interception, and poking at the TDX module guest side interfaces to change which
CPUID leafs generate a #VE.

This is indeed a complication for "the outside". It handles some MSRs accesses
that depend on the CPUID config which it doesn't have final visibility into.

I would like to see less of that in the future. But marking off a certain range
of leafs to be handled by the paravisor/SVSM and that KVM/outside just ignores
seems better than current situation we already have at least. Not to dismiss the
other points.