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: <4f3e1701-3ccd-4ee8-a45e-3872d71ef548@citrix.com>
Date: Tue, 6 Jan 2026 01:44:59 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Dave Hansen <dave.hansen@...el.com>, "Lange, Jon" <jlange@...rosoft.com>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
 "Williams, Dan J" <dan.j.williams@...el.com>,
 Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini
 <pbonzini@...hat.com>, john.starks@...rosoft.com,
 Will Deacon <will@...nel.org>, Mark Rutland <mark.rutland@....com>,
 "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
 LKML <linux-kernel@...r.kernel.org>,
 "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
 "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Subject: Re: "Paravisor" Feature Enumeration

On 05/01/2026 9:42 pm, Dave Hansen wrote:
> First,
>
> Jon and John gave a talk in Tokyo about feature enumeration under
> paravisors:
>
>> https://lpc.events/event/19/contributions/2188/attachments/1896/4057/05-Paravisor-Integration-with-Confidential-Services.pdf
> The tl;dr for me at least was that they'd like a common and consistent
> means of enumerating these features in OSes, regardless of the
> environment: TDX, SEV-SNP or even ARM CCA.

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[*]

I think the discussion would benefit greatly from having a couple of
concrete examples of data this wants to hold, and how it is to be used
at different levels of the interior software stack.

Thanks,

~Andrew

[*] Yes, I know CPUID does have some dynamic properties.  I think most
people would agree that life would be better without them.