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: 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.