[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines.
From: |
Jason Wang |
Subject: |
Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines. |
Date: |
Fri, 31 Mar 2023 16:03:39 +0800 |
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.
Thanks
>
> 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 :|
>
- Re: [RFC PATCH 1/5] ebpf: Added eBPF initialization by fds and map update., (continued)
[RFC PATCH 2/5] virtio-net: Added property to load eBPF RSS with fds., Andrew Melnychenko, 2023/03/29
[RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Andrew Melnychenko, 2023/03/29
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Jason Wang, 2023/03/30
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Daniel P . Berrangé, 2023/03/30
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Jason Wang, 2023/03/31
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Daniel P . Berrangé, 2023/03/31
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines.,
Jason Wang <=
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Daniel P . Berrangé, 2023/03/31
- Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Jason Wang, 2023/03/31
Re: [RFC PATCH 3/5] ebpf: Added declaration/initialization routines., Daniel P . Berrangé, 2023/03/30
[RFC PATCH 4/5] qmp: Added new command to retrieve eBPF blob., Andrew Melnychenko, 2023/03/29
[RFC PATCH 5/5] ebpf: Updated eBPF program and skeleton., Andrew Melnychenko, 2023/03/29
Re: [RFC PATCH 0/4] eBPF RSS through QMP support., Jason Wang, 2023/03/30