Re: [PATCH v2 5/6] qmp: Added new command to retrieve eBPF blob.

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Tue, May 16, 2023 at 04:04:39PM +0200, Markus Armbruster wrote:
>> Daniel P. Berrangé <berrange@redhat.com> writes:
>> 
>> > On Tue, May 16, 2023 at 12:23:28PM +0200, Markus Armbruster wrote:
>> >> Daniel P. Berrangé <berrange@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?