Message-ID: <mykdbrirwar4ymxz4zmkngytdvbixz5lcavawzzjlhefkhisjv@sil5ftirxozp>
Date: Wed, 7 Jan 2026 12:06:25 +0000
From: Kiryl Shutsemau <kirill@...temov.name>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: Jon Lange <jlange@...rosoft.com>, Dave Hansen <dave.hansen@...el.com>, 
	"Williams, Dan J" <dan.j.williams@...el.com>, Sean Christopherson <seanjc@...gle.com>, 
	Paolo Bonzini <pbonzini@...hat.com>, John Starks <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>, 
	"Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Subject: Re: [EXTERNAL] Re: "Paravisor" Feature Enumeration

On Tue, Jan 06, 2026 at 10:39:08PM +0000, Andrew Cooper wrote:
> On 06/01/2026 2:12 am, Jon Lange wrote:
> > Andrew wrote:
> >
> >> 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?
> >> 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.
> > Here are two examples.  In both examples, the OS is running behind a paravisor but I wouldn't term it an "unaware OS".  Rather, the paravisor is present because of the set of services it provides, and it is running in paravisor mode (not SVSM mode) because the implementation benefits from taking full management responsibility for the confidential trust boundary (e.g. determination of when/how to validate/accept pages).  In such a configuration, where the paravisor has management responsibility for the confidential trust boundary, all of the enlightenments in the guest OS for managing confidentiality state must be suppressed.  The straightforward way to do this is for the paravisor to suppress the confidential VM enumeration information visible to the guest OS (the "SNP available" CPUID bit, or the "TDX active" bit, for example).
> >
> > Note that this occurs out of necessity because we can't have the paravisor and the guest OS fighting over who has the right/responsibility to execute PVALIDATE, or TDG.MEM.PAGE.ACCEPT, or whatever.  The kernel today only has two concepts of its execution mode: either it is a confidential VM, in which case it takes full responsibility, or it is not a confidential VM, in which case it ignores the responsibility.  When a paravisor (not SVSM) is active, we have to operate in the second mode because the first mode would provoke precisely the conflict we're trying to avoid. 
> >
> > First example: a confidential VM running under a paravisor wants to obtain an attestation report for itself to pass to a third party to vouch for the fact that it is a confidential VM.  Assume in this example that the relying party is aware of the paravisor and the paravisor's measurements, so the evidence provided in such an attestation report can successfully be verified as authentic.  In order for this to be possible, the kernel has to know that it's running in a confidential VM in a mode where attestation reports are available but where the responsibility for confidential memory state management is suppressed.  This is a third state beyond the two states described above.  This isn't just a userspace problem because access to the attestation service is mediated by a kernel-mode driver that needs to know how to configure itself (such configuration today is based on CPUID and not on ACPI).
> >
> > Second example: a confidential VM running under a paravisor determines that one of the devices available to it is a TDISP device that requires the OS - not the paravisor - to perform the operations required to configure the device, to obtain and verify its attestation information, and to consent to activating the device in the TDISP RUN state.  In order for the OS to be able to execute that sequence, the device has to know that it is running as a confidential VM so it knows that TDISP configuration may be necessary.
> 
> Thankyou - that is helpful.
> 
> So overall, we're wanting the paravisor to be able to express "You're in
> a confidential VM, but you're not in charge" to the OS.
> 
> Hiding the SNP / TDX bit is of course necessary.  They have well defined
> meanings which the OS cannot use when it's not in charge.

Hiding "TDX bit" is not necessary for TDX guest. Linux TDX guest kernel
can run both as L1 and L2 guest. Paravisor in L1 can redirect all
necessary operation to itself and it is transparent for L2.

It might be more relevant for the guest OSes which cannot be run as TDX
guest natively.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov

Powered by blists - more mailing lists