>[...] > >> >>This does not play well with the fact that processes as the PR helper >> >>are always required. >> >> >> >>Merging them into libvirtd would make the VM stop until libvirtd is >> >>running again. Additionally if any of the operations require persistent >> >>kernel state as e.g. file descriptors, this would be impossible as >> >>stopping libvirtd process would close the FDs which may be then >> >>impossible to reopen properly e.g. due to state. >> > >> >Thanks! Besides these reasons above, will it weaken security if we let libvirtd >do >> >these jobs? For example, >> >Such sayings, like "libvirtd would become the focus from attacking forces", >make >> >sense? >> >> If there's no security concern, then, will it be OK to add a new KVM ioctl, which >allows >> qemu to ask kvm module to do the high prilidged jobs? > >Well there actually is security concern in qemu. Libvirt attempts to run >qemu with the least amount of privileges possible as the 'untrusted' >guest interacts directly with qemu. > >That is in the end the reason 'qemu-pr-helper' exists separately. Then, suppose we have this scenario: 1 Inside the guest, the user binds certain irqs to certain vcpus 2 qemu helps to bind the irqs to the pcpus Besides letting another agent daemon(similar to pr-helper) to do the binding job, can we add a new KVM ioctl and let qemu call kvm module to do the binding job? -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
