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. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
