PUCK follow up: Trusted IO call details

PUCK follow up: Trusted IO call details

[Edgecombe, Rick P]

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. Also, it appears to be
canceled this week.

Re: PUCK follow up: Trusted IO call details

[Xu Yilun]

On Wed, Apr 15, 2026 at 06:59:05PM +0000, Edgecombe, Rick P 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. Also, it appears to be
> canceled this week.

Here is the Link to Dan's call.

https://zoom-lfx.platform.linuxfoundation.org/meeting/93219227394?password=80705486-101a-4e19-8f11-0baaf92104be

Dan said "The April 16th instance will be cancelled, but will pick it
back up on the regular schedule on April 30th"

Thanks,
Yilun

Re: PUCK follow up: Trusted IO call details

[Paolo Bonzini]

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

Paolo

Re: PUCK follow up: Trusted IO call details

[Edgecombe, Rick P]

On Thu, 2026-04-16 at 14:59 +0200, Paolo Bonzini wrote:
> This one is friendly (9AM PST = 6PM CEST). The unfriendly one is the
> IOMMUFD one (5AM :)).

Haha, the link Yilun just posted says 8pm PST. "Kernel-SIG" was the one I was
trying point out, at least.

Re: PUCK follow up: Trusted IO call details

[Dan Williams]

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

Then there are the next steps with the uapi to convey PCI device
attestation that was proposed here [1], and also discussed as part of
the Rust SPDM proposal [2].

[1]: http://lore.kernel.org/20260303000207.1836586-9-dan.j.williams@intel.com
[2]: http://lore.kernel.org/69976d7d39c60_2f4a1009@dwillia2-mobl4.notmuch

Re: PUCK follow up: Trusted IO call details

[James Bottomley]

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:

https://man7.org/linux/man-pages/man1/ncat.1.html


Regards,

James

Re: PUCK follow up: Trusted IO call details

[Dan Williams (nvidia)]

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.

Re: PUCK follow up: Trusted IO call details

[James Bottomley]

On Thu, 2026-04-30 at 18:29 -0700, Dan Williams (nvidia) wrote:
> 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.

Hey, that's OK and congratulations on the new gig, by the way.

>  The problem with virtio-vsock is that it is built to terminate in
> guest userspace not in the kernel.

Um, I believe the ksocket API can terminate any socket type in the
kernel (including vsock):

https://www.kernel.org/doc/html/next/networking/kapi.html

That's how we do things like netlink termination (and NFS, of course).

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

So this is OVMF being able to open AF_VSOCK?  That is true today, but
it already has socket APIs for https boot, so they should be easily
extensible.

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

Well, this is a separate problem, but one I'm also interested in since
I'm looking at bringing the hyper-v VMPL like API to kvm, which also
needs this type of communication between the various planes.

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

Well, OK, but if you do this, it needs to be usable both for guest to
host and for plane to plane in the guest.

Regards,

James