[libvirt] Can jobs suck like qemu-pr-helper does be transfered to libvirtd?
Hi all: qemu-pr-helper exits to help qemu do the high-privileged scsi related jobs. LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set selinux/DAC labels for them and their socket. # # # # # ___________ # ___________|libvirtd |__________ # | |___________| | # | | | # | | | # _________|________ _____|______ ___|____ # | qemu-pr-helper |__| vm1.sock |_____| qemu1 | # |__________________| |____________| |________| There may be other jobs quite like qemu-pr-helper, shall we make them as "complex" as the qemu-pr-helper scheme? Will it be OK to just let qemu send an EVENT to libvirtd, and let libvirtd do the SCSI/other jobs? Will it be OK if we remove qemu-pr-helper and similar processes? What's the disadvantage if we let libvirtd do there high privileged jobs instead qemu-pr-helper-like processes? Thanks!
On Mon, Mar 18, 2019 at 11:24:03 +0000, Zhangbo (Oscar) wrote:
Hi all: qemu-pr-helper exits to help qemu do the high-privileged scsi related jobs. LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set selinux/DAC labels for them and their socket.
# # # # # ___________ # ___________|libvirtd |__________ # | |___________| | # | | | # | | | # _________|________ _____|______ ___|____ # | qemu-pr-helper |__| vm1.sock |_____| qemu1 | # |__________________| |____________| |________|
There may be other jobs quite like qemu-pr-helper, shall we make them as "complex" as the qemu-pr-helper scheme? Will it be OK to just let qemu send an EVENT to libvirtd, and let libvirtd do the SCSI/other jobs? Will it be OK if we remove qemu-pr-helper and similar processes? What's the disadvantage if we let libvirtd do there high privileged jobs instead qemu-pr-helper-like processes?
No what you describe is not desired. Any process which is vital for the runtime of the VM needs to stay as simple and minimal as possible and separate from libvirtd. Libvirtd is a complex big application dealing with multiple things at once and also the architecture allows for libvirtd to be stopped and upgraded. 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.
qemu-pr-helper exits to help qemu do the high-privileged scsi related jobs. LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set selinux/DAC labels for them and their socket.
# # # # # ___________ # ___________|libvirtd |__________ # | |___________| | # | | | # | | | # _________|________ _____|______ ___|____ # | qemu-pr-helper |__| vm1.sock |_____| qemu1 | # |__________________| |____________| |________|
There may be other jobs quite like qemu-pr-helper, shall we make them as "complex" as the qemu-pr-helper scheme? Will it be OK to just let qemu send an EVENT to libvirtd, and let libvirtd do the SCSI/other jobs? Will it be OK if we remove qemu-pr-helper and similar processes? What's the disadvantage if we let libvirtd do there high privileged jobs instead qemu-pr-helper-like processes?
No what you describe is not desired. Any process which is vital for the runtime of the VM needs to stay as simple and minimal as possible and separate from libvirtd.
Libvirtd is a complex big application dealing with multiple things at once and also the architecture allows for libvirtd to be stopped and upgraded.
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?
qemu-pr-helper exits to help qemu do the high-privileged scsi related jobs. LIBVIRTD is responsible to launch qemu-pr-helper and qemu, and set selinux/DAC labels for them and their socket.
# # # # # ___________ # ___________|libvirtd |__________ # | |___________| | # | | | # | | | # _________|________ _____|______ ___|____ # | qemu-pr-helper |__| vm1.sock |_____| qemu1 | # |__________________| |____________| |________|
There may be other jobs quite like qemu-pr-helper, shall we make them as "complex" as the qemu-pr-helper scheme? Will it be OK to just let qemu send an EVENT to libvirtd, and let libvirtd do the SCSI/other jobs? Will it be OK if we remove qemu-pr-helper and similar processes? What's the disadvantage if we let libvirtd do there high privileged jobs instead qemu-pr-helper-like processes?
No what you describe is not desired. Any process which is vital for the runtime of the VM needs to stay as simple and minimal as possible and separate from libvirtd.
Libvirtd is a complex big application dealing with multiple things at once and also the architecture allows for libvirtd to be stopped and upgraded.
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? Because kvm module reacts much faster than libvirtd and it never get "restarted" like libvirtd. All the problems talked above(security concerning excluded) with libvirtd seems nonsexist for kvm module.
On Fri, Mar 29, 2019 at 02:21:00 +0000, Zhangbo (Oscar) wrote: [...]
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.
[...]
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?
On Tue, Apr 02, 2019 at 06:44:13 +0000, Zhangbo (Oscar) wrote:
[...]
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
Binding virtual cpus to physical cpus is usually done via libvirt at this point but it's not automatic. Any automatic pinning approach must not override the pinning set on the host side.
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?
Your description of what you want to do is not very specific. At any rate if the automatic setting approach has always better properties and does not override limits configured on the host side it should be considered as a good idea. Just don't forget that the gues OS is always treated as untrusted so you should make sure that any input you consider from the guest is treated as such. Depending on "realtimeness" requirements of the operation you want to do bud did not describe properly any of the approaches you describe may make sense. One other, if the operation is not critical and thus can wait is to implement it via a QMP event + query command where libvirt can respond do that. The situation really depends on what you are doing. In case of the pr-helper it is not possible to wait for libvirt to do it as it has IO implications.
participants (2)
-
Peter Krempa -
Zhangbo (Oscar)