Re: [PATCH hyperv-next v4 15/16] Drivers: hv: Support establishing the confidential VMBus connection

[Roman Kisel <romank@linux.microsoft.com>]

On 8/25/2025 4:00 PM, dan.j.williams@intel.com wrote:
> Roman Kisel wrote:
> [..]
>> This doesn't replace TDISP, I'll do a better job of supplementing the code changes
>> with documentation and comments! Any suggestions are greatly appreciated.
> 
> No, I am not asking for documentation and comments and I am asking how
> any of the security claims are validated by this partially enabled L2
> guest?
> 

As the guest is partially enabled, it relies on the trusted paravaisor
which is fully enabled wrt running in a hardware isolated VM. The
paravisor image is measured, there is attestation flow, and the hardware
validates the paravisor image.

[...]

>> The patch set is a building block for building a confidential I/O path for the non-fully
>> enlightened Linux guests. It would be great to have the Linux storage and network stack not
>> to share pages with the host (and not bounce-buffer) if the storage and network are
>> paravirtualized && use the Confidential VMBus. In the first version of the patchset I had
>> patches for that, yet that was considered too naive to be merged in the main line kernel so
>> I dropped them. But even without that, this patch series protects the control plane and the
>> data plane from the host with the exception of the pages the guest might use for bounce-buffering
>> although it could've avoided that in this case.
> 
> The question is what protects against the paravisor lying about its
> identity? If the L2 guest is partially aware that a paravisor is
> providing confidentiality then it needs some interaction with a relying
> party to say "yes, this paravisor is indeed what it claims to be". Is
> that some indicator passed over an established / trusted channel that I
> overlooked?
> 

Trying to understand the question, thinking out loud. The paravisor is
running within the same GPA space as the guest, the host/hv cannot
access the CPU context and the memory assigned to the paravisor and the
guest until they share the pages, the paravisor is measured and goes
through attestation. From that, the customer has the control over the
chain of trust. They can rebuild the paravisor if they wish to do so.

>> I mentioned that the paravisor will be handling the TDISP device for such guests.
>> As folks might know, we use the OpenHCL paravisor which is a Linux kernel with the VTL
>> mode patches we've been upstreaming (links to the repos are in the cover letter), and
>> the OpenVMM running in the user land. The question would be if TDISP isn't available
>> in the Linux kernel, how one would get it working in the OpenHCL paravisor that itself
>> runs Linux? The SEV guest device in the paravisor kernel is being extended to handle
>> TIO. Once TDISP support is available in the mainline kernel, the paravisor will switch
>> to using the mainline implementation.
> 
> Either the L2 is unenlightened and has all its mapping attempts trapped
> and redirected to be encrypted, or the L2 is partially enlightened and
> at a minimum validates the identity of the paravisor.

-- 
Thank you,
Roman