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

[<dan.j.williams@intel.com>]

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?

> A fully-enlightened Linux guest could just use TDISP once support for that is available
> in the Linux kernel. Before it is, the non-fully enlightened Linux guests (they can only deal
> with accepting memory and sharing memory with the host) could rely on the paravisor to talk
> to such devices. The TDISP device will be connected to the paravisor, and the paravisor will
> provide the paravirtualized storage and network over the VMBus channels to the Linux guest.

Yes, that is understood, again that is not the question.

> 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?

> 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.