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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Mar 31, 2023 at 04:03:39PM +0800, Jason Wang wrote:
> On Fri, Mar 31, 2023 at 3:59 PM Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > 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.
> 
> Well, this means the QMP command is safe only before Qemu starts to
> run VCPU. I'm not sure this is a good design. Or at least we need to
> fail the QMP command if VCPU starts to run.

Currently QEMU has the ability to just create the eBPF programs itself
at will, when it is launched in a privileged scenario regardless of
guest CPU state. In terms of QMP, the reporting of QEMU PIDs for its
various vCPU, I/O threads is also not to be trusted after vCPU starts
if the guest workload is not trustworthy.  I feel this is more of docs
problem to explain the caveats that apps should be aware of.


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