On Fri, Mar 31, 2023 at 4:13 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > > 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é <berra...@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é > > > > <berra...@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 > > > > > > <and...@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.
Indeed. > I feel this is more of docs > problem to explain the caveats that apps should be aware of. Ok, we can probably document this and in the future we probably need to address them. 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 :| >
