Re: [Xen-devel] QEMU XenServer/XenProject Working group meeting 10th February 2017

[Jennifer Herbert <Jennifer.Herbert@xxxxxxxxxx>]

QEMU XenServer/XenProject Working group meeting 10th February 2017
==================================================================

Attendance
----------

Andrew Cooper
Ian Jackson
Paul Durrent
Jennifer Herbert
George Dunlap
Igor Druzhinin
Sergey Dyasli


First topic: DMop
-----------------

After an introduction, Paul started by describing his recent progress 
with Dmop.
He has posted a privcmd series, including the dmop hypervisor parts.  
This adds the dmop ioctl and the restriction ioctl.  This restrict 
ioctl, restricts access of the dmop to that of the given domain, and 
prevents further access via the privcmd.
Paul has also written all the code for libdevicemodel -  4 patches. This 
code is linux specific, and will detect if its running on an OS it doest 
support (either old linux or windows), or where the privcmd driver 
doesnt support the dm ioctl.
He next intends add a compatibility layer  to libxenctl, which reroutes 
old xc calls to the new way.
This would make the make calls switch transparently, but you'd know at 
the time you made the restriction call, if it succeeded or not, and can 
use local policy to determine if to continue or not.
Following this, QEMU needs to be ported onto this new library.

Next was a lengthy discussion QEMU's mapcahe, and on how to secure mmap 
calls.  It was eventual concluded that Paul could just extend his 
current patches to also include the mmap calls.
It was asked if using this library would mean having two fds,  but this 
was said to be only true if you continued to keep xenctl open – which 
you shouldn’t since the new restricted ioctl fd should be able to do 
everything you might need the old one for.
Paul detailed how the privcmd driver now has a domid associated with 
each fd, which defaults to 'invalid'.  The restrict ioctl sets this 
domid, and from then on, every call from that fd is checked against that 
domain.  The restrict ioctl won't allow the domid to be changed again 
later.
It was suggested other calls should be checked, but Paul didn't think 
there where any others not already discussed.

Next topic: How to prevent QEMU running as root
-----------------------------------------------

There is a patch to so make QEMU change away from root user.  This is 
expected to make a number of things stop working:
* CD-ROM insert  -   Eject is expected to work, if you could insert one.
* Emulated hotplug - unsure.
* PCI-passthough – This is deemed out of scope since pci-passthough 
inherently unsafe anyway.  It should give a useful error message 
suggesting turning off de-priv.  This could be made to work in future.
It is thought that some of these problems could be solved by passing fds 
over QMP.  Furthermore, it was thought that DavidV. had looked, and 
found you could already do this.  If so, only toolstack changes would be 
needed.  Making emulated network hotplug or IDE hotplug work is probably 
not important.
NOTE: Need to check QMP and it applicability to this problem.


Next Topic: Xenstore
--------------------

Juergen has a proposal for xenstored, to have something similar to dm-op 
ioctl.  Each command can have a prefix which requests it's executed with 
a specified domain security context.
Its also necessary to run the multilpe QEMUs, such that the PV back-ends 
can be run in a separate instance from the emulators.  In doing this, 
you also need to separate out the xenstore paths, such that each QEMU 
uses its own xenstore branch.
Part of the reason is that the backend paths that you are using to 
control the emulated deprivileged QEMU, have to be writeable by the 
guest. This is because the emulated QEMU is going to have to write to them.
The emulator patch ID stuff is already upstream – and can be invoked.   
But toostack has to be able to cope.  Ian wrote a LibXL patch series 
(20~30 patches) 18 months ago, but that has bit rotted.  This patch was 
said to be surprisingly long.
Andrew is concerned that giving a guest permission to write to the 
xenstore paths used by its QEMU may cause a significant security issue, 
while others think it would merely offer a new way for it to crash 
itself.  Andrew to inspect Ian's patch series to evaluate this risk.
There are only a hand full of xenstore paths needed by the emulated QEMU 
– which will only drop as QMP use increased.
Another thing to consider is you'll have to be able to talk to multiple 
QEMU's via QMP – knowing which is which!
There was a suggestion that you could differentiate between QEMU pv and 
QEMU emulated by how your communicating with it – but this wouldn't 
really be possible, as QEMU upstream won't accept anything using 
xenstore, if it might be useful to more then just the xen community.

XenServer is currently working towards moving to QEMU upstream, with 
it's core functionally currently working using temporary python shims, 
translating the API calls.  If depriv is unstreamed in time, XenServer 
won't have to transition the APIs twice.
Given this, it was decided it would be easiest for LibXL to tested with 
the changes first, and see how well it QEMU works as not-root.
Next Topic:  Drop Caps
----------------------

Andrew points out that there is more to running without root privileges 
then just changing your UID.  He recalls how a past college has needed 
to us drop-caps, and moved things to an anonymous name space, to prevent 
things like being able to open TCP sockets.
Doing such operations are Linux specific, but as long as such operations 
are enabled by an option, this is ok.  It was concluded these where 
incremental benefits which could be done later, after we got the basics 
working.  This issue also not Xen specific.


Action Items
------------

Paul to carry on with Xen device model work.

Ian to re-factor LibXL after libxl split.

Ian to negotiate xenstore restrictions

Ian to check QMP can take an fd and use for CD insert and emulated hotplug.

Andrew to look over Ian's patchqueue to see how bad giving a guest the 
extra xenstore permissions
would be.

Jennifer to continue leading Xenservers change over from QEMU trad to 
the use of QEMU upstream.   XenServer is making slow progress here, but 
not highest priority.

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