XenProject/XenServer QEMU working group, Friday 8th July, 2016, 15:00.
Date and Attendees
==================
XenProject/XenServer QEMU working group, held on Friday the 8th of July,
2016 at 15:00.
The Following were present:
Ian Jackson [platform team]
David Vrabel [ring0]
Andrew Cooper [ring0]
Jennifer Herbert [ring0]
Purpose of meeting
==================
Both XenServer (currently using qemu-trad with de-priv) and XenProject
(using QEMU (upstream) without dep-priv), would like to move to using
QEMU (upstream) de-privelaged.
This meeting was intended to restart XenServer/ring0 and XenProject's
collaboration.
Agenda includes:
* Discuss requirements
* Review the our status and strategy on achieving these requirements.
* Agree next steps.
Meeting Actions
===============
Ian: Find all the Xenstore keys used by QEMU, and evaluate how much work
it would be to either read before privileges are dropped, or
otherwise stop reading/writing them when de-privelaged.
Ian: Write up DM_Opp design (discussed during meeting), talk to Jan
about this.
XenServer: Go though All the priv-cmd ops, check how they would fit
within the dm-opp design.
David: Post Event channel / priv command patch to upstream. (Now done)
Meeting Transcript - abridged
=============================
Discussed Goals
---------------
Everyone agrees we want to stop anything gaining control of QEMU from
also gaining access to the platform.
XenProject would like to use depriv by default. Should not preclude
other configurations such as PCI pass though.
Ian: There is a project in progress to use stub domains with QEMU –
would expect a user to run depriv or stubdoms, but not at the same
time.
XS: states that is does not want to go down the stub domains route, as
is not considered scalable. (Boot storms etc;)
Ian: In upstream we expect to pursue both depriv qemu, and stub qemu, as
implementation strategies. Depriv qemu is probably deliverable
sooner. Stub qemu is more secure but not suitable for all users
(eg, maybe not for XenServer as David suggested).
Going though list technology areas listed in document shared beforehand.
Disk / Nsetwork / Host IO
-------------------------
Can be addressed by running as unprivileged user. Andrew: Rather
linux centric - not posix solution for all these problem: Ian: There
are similar interfaces on other platforms. In upstream we expect to at
least be able to run as an unprivileged user, which is indeed portable.
Mem map
------------
XenServer has a solution. Ian: Would like to see this shared
immediately. Andrew: Consider rest of design first.
HyperCalls
----------
Three options:
1: XSM
2: Fix ABIan: Re-arrange priv-cmd to make it easier to parse and
restrict.
3: Loadable pattern matching solution. All agree this would be
horrible to maintain.
Ian: Difference between not having Stable API, and the instability of
ABI stopping the determination of domain.
Ian: Version compatibility out of scope. Andrew: Disagree, should do
both together.
Andrew: Requirement: – no interdependence between QEMU and the kernel,
such that you need to update both together.
All: Agree xen interface should not be embedded in the kernel.
Jen: Asked why Ian was against using XSM.
Ian: XSM wholesale replace existing checks, and current XSM polices are
unproven.
Andrew: XS is experimenting, and there are problems.
Ian & Andrew: Agree would need auditing.
Ian: Reluctant to link xsm to this work.
David: Can do both – XSM and 'Fix ABI'.
Ian: With both, wouldn't need the nesting.
David: Would still need to nesting to wrap domains.
Ian: Doesn't have to do all ….
David: <Unconvinced>
David: (wearing a linux hat): Sceptical for stable API – don't want to
have a new kernel when API new features added.
Ian: Suggest ideas of DM-Space – D-ctrl space.
David: Would need to be a strong component. Both ends would want
commitment ~ no snow flakes.
Ian: Shouldn't be a ploblem.
Andrew: PVH would relpcaes QEMU. Ian: Not relevant.
Idea of DM-ops is discussed more.
Dm-op restricted to domain
No need to version this.
Important fields (domain) fixed, such that DM-ops can be added
changed, without affecting kernel interface.
Andrew bring up XenGT. Is this considered part of QEMU. QEMU
shouldn't set pci bars.
Question if DM-OP would just be HVM-OP.
David: Should enumerate hyper-calls, make sure in DM-ops.
Andrew & Ian : would need to discuss with Jan.
Some things may need to be in both dm-op & other things, ie guest
interface. - This is ok.
dm-ops is tentatively agreed on as a way forward.
XenStore Restrict.
------------------
Jen : Upstream discussing maybe dropping sockets. (Necessary for
restrict)
David: Problem, is it gives the same permissions as the guest – does
this restrict too much?
Should look though all uses, see if they can be used before it drops
privileges.
Ian: Already looked at QEMU PV backend/DM spilt work. - This work was
awkard disjoint work. I think this approach would work.
Jen: Brought up Physmap keys in xenstore… All agree this isn't nice.
Andrew: Mentions memory accounts swamp he wants to sort out.
Others: - don't want to tie this work to that.
Ian: Guest can blow of its own head – physmap not great, but ok.
Need to get Xenstore keys, so see issues.
Ian: Happy to say everyone should move to xenstore-d, but need to find
way to multiplex this, such that it can be used from stub domains.
Need some sort of plan.
New ring – not good idea. Alternative plan, prefix command.
Andrew: Protocol command?
David: not like that idea.
Ian: Huge patch needed to separate PV-QEMU from DM part, running in
separate qemus.
David: XenSever has no PV part, so XS dodges this issue.
Ian: Might be xenstore path issues, if not to use the switch.
David: It may be that we can remove all use of xenstore while
deprivelaged, we could avoid the need for xenstore changes.
Agreed someone would need to look though remaining uses, to see how much
work this would be.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
