Re: PUCK follow up: Trusted IO call details

["Dan Williams (nvidia)" <djbw@kernel.org>]

James Bottomley wrote:
> On Thu, 2026-04-16 at 19:37 -0700, Dan Williams wrote:
> > Paolo Bonzini wrote:
> > > On Wed, Apr 15, 2026 at 8:59 PM Edgecombe, Rick P
> > > <rick.p.edgecombe@intel.com> wrote:
> > > > 
> > > > The call I mentioned is officially called: "TAC Subcommittee:
> > > > Linux Kernel Special Interest Group (Linux Kernel-SIG)". This
> > > > seems to be the info:
> > > > https://confidentialcomputing.io/about/committees/#Linux-Kernel-SIG
> > > > 
> > > > Paolo, unfortunately I did remember correctly that it is not an
> > > > EU friendly time.
> > > 
> > > This one is friendly (9AM PST = 6PM CEST). The unfriendly one is
> > > the IOMMUFD one (5AM :)).
> > 
> > There are couple topics at present that would be suitable to raise at
> > the EU-US friendly time. Specifically whether all of the per-arch
> > implementations of "transport large attestation evidence blobs over
> > shared memory from host-to-guest" would be better served with a
> > shared generic transport (simple virtio-pipe / something equivalent
> > for vmbus to publish).
> 
> Sorry to be a bit late to the party, but why invent a new thing
> (virtio-pipe), why not use the existing virtio-vsock (and hyperv-vsock,
> so no new vmbus device is needed)?  If you're thinking it's because you
> need a simple cat into host and out of guest, then you can do that with
> the ncat --vsock utility:

I missed replying to this while I was on break. The problem with
virtio-vsock is that it is built to terminate in guest userspace not in
the kernel. I want to see the same flow for bare metal retrieval of
device attestation blobs as guests, which points to not having a
userspace indirection dependency for the PCI core.

I have also heard concerns of the complexity / availability of vsock
early in the boot flow (firmware?). For that concern a "simple" pipe
protocol, like drivers/virt/coco/tdx_guest implements, pulls the blob
over instead. Except, now we have simple drivers/virt/coco/arm-cca-guest
transport, and simple drivers/virt/coco/sev-guest transport all
duplicating blob retrieval over shared memory with payload size quirks
and bugs.

The problem is about to get worse with TEE I/O because all of these
archs have defined extension blob retrieval interfaces for the new PCI
material. That duplication is not in Linux's long term interest, so a
common "blob transport over shared memory" implementation is the
proposal. virtio has already done the work to handle arbitrary data
transfers, no need to reinvent that wheel. The only hangup is that we
would still need a vmbus filter to feed the same mechanism.