On 10/09/2017 05:01 PM, Ian Jackson wrote:
We need to restrict *all* the control fds that qemu opens. Looking in
/proc/PID/fd shows there are many; their allocation seems scattered
throughout Xen support code in qemu.
We must postpone the restrict call until roughly the same time as qemu
changes its uid, chroots (if applicable), and so on.
There doesn't seem to be an appropriate hook already. The RunState
change hook fires at different times depending on exactly what mode
qemu is operating in.
And it appears that no-one but the Xen code wants a hook at this phase
of execution. So, introduce a bare call to a new function
xen_setup_post, just before os_setup_post. Also provide the
appropriate stub for when Xen compilation is disabled.
We do the restriction before rather than after os_setup_post, because
xen_restrict may need to open /dev/null, and os_setup_post might have
called chroot.
This works for normally starting a VM but doesn't seem to work when
resuming/migrating.
Here is the order of selected operations when starting a VM normally:
VNC server running on 127.0.0.1:5901
xen_change_state_handler()
xenstore_record_dm_state: running
xen_setup_post()
xentoolcore_restrict_all: rc = 0
os_setup_post()
main_loop()
Here is the order of selected operations when starting QEMU with
-incoming fd:... :
VNC server running on 127.0.0.1:5902
migration_fd_incoming()
xen_setup_post()
xentoolcore_restrict_all: rc = 0
os_setup_post()
main_loop()
migration_set_incoming_channel()
migrate_set_state()
xen_change_state_handler()
xenstore_record_dm_state: running
error recording dm state
qemu exited with code 1
The issue is that QEMU needs xenstore access to write "running" but this
is after it has already been restricted. Moving xen_setup_post() into
xen_change_state_handler() works fine. The only issue is that in the
migration case, it executes after os_setup_post() so QEMU might be
chrooted in which case opening /dev/null to restrict fds doesn't work
(unless its new root has a /dev/null).
--
Ross Lagerwall
