Re: [Xen-devel] [PATCH 3/8] xen: defer call to xen_restrict until just before os_setup_post

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Ross Lagerwall writes ("Re: [PATCH 3/8] xen: defer call to xen_restrict until 
just before os_setup_post"):
> 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).

Thanks for the extensive diagnosis.

We do in fact want the restriction to occur before the migration
stream is read.  This is because we are trying to defend against a
guest which can exploit a bug in qemu.  That means that the sending
qemu must be assumed to be compromised.  In this context I don't think
qemu's migration stream receiver can be regarded as hardened against
hostile input; it's far too complicated, even if efforts have been
made in that direction (I haven't checked).  So to avoid the receiving
qemu being compromised while still unrestricted, we should restrict
before starting to read the migration stream.

The correct fix is to use a different technique to notify the
toolstack that qemu is up and running.  That obviously requires
changes on the Xen tools side.  I will look into that for the Xen 4.11
release cycle.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel