Daniel P. Berrangé <berra...@redhat.com> writes: > On Tue, May 16, 2023 at 04:04:39PM +0200, Markus Armbruster wrote: >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >> > On Tue, May 16, 2023 at 12:23:28PM +0200, Markus Armbruster wrote: >> >> Daniel P. Berrangé <berra...@redhat.com> writes: >> >> >> >> > On Tue, May 16, 2023 at 10:47:52AM +0200, Markus Armbruster wrote: >> >> >> >> [...] >> >> >> >> >> So, this is basically a way to retrieve an eBPF program by some >> >> >> well-known name. >> >> >> >> >> >> Ignorant question: how are these programs desposited? >> >> > >> >> > The eBPF code blob is linked into QEMU at build time. THis API lets >> >> > libvirt fetch it from QEMU, in base64 format. When libvirt later >> >> > creates NICs, it can attach the eBPF code blob to the TAP device (which >> >> > requires elevated privilleges that QEMU lacks). NB, libvirt would fetch >> >> > the eBPF code from QEMU when probing capabilities, as once a VM is >> >> > running it is untrusted. >> >> >> >> Okay, I can see how that helps. I trust the blob is in a read-only >> >> segment. Ideally, libvirt fetches it before the guest runs. >> > >> > Whether the blob is in a read-only segment or not isn't important, >> > because it transits writable memory in the QMP command marshalling. >> >> True. We could bypass marshalling. Unclean hack. Or we could sign the >> bits cryptograhically. Key management headaches. Not worth it, because >> fetching it before QEMU becomes untrusted is easier. >> >> However, I now wonder why we fetch it from QEMU. Why not ship it with >> QEMU? > > Fetching it from QEMU gives us a strong guarantee that the eBPF > code actually matches the QEMU binary we're talking to, which is > useful if you're dealing with RPMs which can be upgraded behind > your back, or have multiple parallel installs of QEMU.
Yes, but what makes this one different from all the other things that need to match?
