qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines.


From: Daniel P . Berrangé
Subject: Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines.
Date: Fri, 31 Mar 2023 08:59:11 +0100
User-agent: Mutt/2.2.9 (2022-11-12)

On Fri, Mar 31, 2023 at 03:48:18PM +0800, Jason Wang wrote:
> On Thu, Mar 30, 2023 at 4:34 PM Daniel P. Berrangé <berrange@redhat.com> 
> wrote:
> >
> > On Thu, Mar 30, 2023 at 02:54:32PM +0800, Jason Wang wrote:
> > > On Thu, Mar 30, 2023 at 8:33 AM Andrew Melnychenko <andrew@daynix.com> 
> > > wrote:
> > >
> > > Who or how the ABI compatibility is preserved between libvirt and Qemu?
> >
> > There's no real problem with binary compatibility to solve any more.
> >
> > When libvirt first launches a QEMU VM, it will fetch the eBPF programs
> > it needs from that running QEMU using QMP. WHen it later needs to
> > enable features that use eBPF, it already has the program data that
> > matches the running QEMU
> 
> Ok, then who will validate the eBPF program? I don't think libvirt can
> trust what is received from Qemu otherwise arbitrary eBPF programs
> could be executed by Qemu in this way. One example is that when guests
> escape to Qemu it can modify the rss_bpf__elf_bytes. Though
> BPF_PROG_TYPE_SOCKET_FILTER gives some of the restrictions, we still
> need to evaluate side effects of this. Or we need to find other ways
> like using the binary in libvirt or use rx filter events.

As I mentioned, when libvirt first launches QEMU it will fetch the
eBPF programs and keep them for later use. At that point the guest
CPUs haven't started running, and so QEMU it still sufficiently
trustworthy.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]