Re: [Hackathon 16] Notes from Security Session

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> On 19/04/16 10:02, Doug Goldstein wrote:
> >On 4/18/16 12:20 PM, Lars Kurth wrote:
> >>Hi all,

CC-ing XSM maintainer :-)
> >>
> >>I took notes as much as I could. CC'ed the people who participated most. If I missed/misrepresented something, please add to the discussion. I know that George for example took some extra notes in the one or other area.
> >>
> >>Regards
> >>Lars
> >>
> >>== Topics discussed ==
> >>QEMU
> >>De-privilige of QEMU
> >>XSA
> >>x-Splice
> >>x86 Emulator
> >>Enabling XSM By default
> >>
> >>=== Slimline QEMU ===
> >>
> >>Konrad: Some inroads on making QEMU better
> >>Konrad: QEMU is too big and it is hard to strip down the platform : how can we chop it up
> >>
> >>Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU model, which was rejected at the time
> >>Stefano: Maybe what we need is different
> >>Stefano: Containers / Intel have similar issues
> >>Stefano: Intel have a very similar problem with ClearContainer
> >>Stefano: Re-implementing ClearContainers with QEMU because of market needs
> >>Stefano: QEMU does have already a no-default option
> >>
> >>Doug: In the QEMU model: you cannot run a board without a CPU
> >>Doug: KConfig may be acceptable, but re4moving boards may not (initially discussed with Antony L)
> >>
> >>George: Distros don't want to ship two versions of QEMU
> >>George: Compile configurability doesn't help with distros
> >>
> >>Konrad: PVH/HVMLite does not use QEMU (or only as a back)
> >>
> >>Lars: If we had a proposal, working with Intel and the QEMU community, we could discuss at Xen Summit / KVM Forum is co-located
> >>
> >>James: If we had a future with OVMF, then we probably wouldn't need QEMU (aka if you want security use PVH with OVMF)
> >>James: Proposal for security conscious applications we could fork and use a stubbed out version of QEMU
> >>
> >>Options:
> >>- KConfig
> >>- Run-time disablement
> >>- Xen Summit / KVM Forum
> >>- Intel work / collaboration
> >>- PIX3 > 935
> >>- OVMF
> >>- Remove xl.cfg (stop configs - in fact we probably only can print a warning "this is not secure and has no security support" or something similar)
> >>
> >>Doug: Issue
> >>- For example Oracle could deal with Config
> >>- BUT, this approach won't work for distros
> >>
> >>ACTION: Konrad is volunteering to drive this discussion
> >>
> >>=== De-privilige Qemu ===
> >>Konrad: What's the status
> >>Stefano: not done, you need
> >>- QEMU as non-root (that is in 4.7 and QEMU part is there)
> >>- Now you still have a libxc and xenstore interface that needs to be de-priviliged
> >>   - There is a patch for QEMI and xenstore to deal with the libxc part (not upstreamed) ... pretty big series, but won't make it for 4.7 - QEMU part is tiny
> >>   - Libxc is sizeable (Ian Campbell was working on it), but it is now dormant : QEMU support is there, but Dom0 interface is missing
> >>     - Ideas: Do registration in Dom0
> >>[George has some additional notes]
> >>
> >>ISSUE: A proposal and a plan, but nobody to do this. Without this what we have is not useful
> >>Andrew: XenServer still using qemu-trad because of some gaps in emu-upstream
> >>Andrew: XS may end up working on this at some undefined point in the future
> >>
> >>There is a problem with using CD drive's to open ISOs as you need to be privileged to do this
> >>Andy Cooper: there may be real end-user issues
> >>Stefano: Could change ownership
> >>Doug: Issue was tried to be fixed in libvirt and went nowhere
> >>Andy: Qemu-trad does it wrong (QEMU in libxenlight does not do that)
> >>
> >>ACTION: High;right lack of owner
> >>
> >>Konrad: Seccomp may work
> >>Doug: everything has to be passed as file descriptor
> >>
> >>=== Narrower XSA Coverage ===
> >>Jan: XSA 77 (whitelisted a set of dom control and sys control) which are supposedly ... http://xenbits.xen.org/xsa/advisory-77.html
> >>      See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Security Status of dom0 disaggregation)
> >>Jan: Who runs this in production: running part of toolstack not in Dom0 - OpenXT wants to do this
> >>Jan: The observation is that we went to far with the XSA 77 => if we had a shorter whitelist, and reduce whitelist
> >>Jan: If there was agreement, then the security team
> >>  would not handle issues in these areas as XSA's
> >>
> >>Ross Phillipson: Typic ally we have only higher level stuff in a different xl, but lower level stuff runs on Dom0. So there should be no issue
> >>
> >>George: QEMU stub domains should have security support
> >>George: There are a whole set of other things, which we don't know whether they are used
> >>George: Do we want to security support of disaggregated tools-stub
> >>
> >>Agreed: Propose patch to change http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt on the list
> >>Jan: We can only discuss in public if no issues are pending
> >>Cc: Christopher Clark <christopher.w.clark@gmail.com>, Ross Philipson <ross.philipson@gmail.com>, Daniel Smith <dpsmith@apertussolutions.com>
> >>CC the folks on this thread or openxt@googlegroups.com (OpenXT mailing list)
> >>
> >>=== x86 Emulation de-privilige ===
> >>Anthony is working on it
> >>Stefano: I think you had some measurements
> >>Anthony: Measurements were not very good
> >>Andrew: If you are introspecting, you sacrifice 70% performance
> >>Andrew: Patches were very complicated
> >>Andrew: Re-writing the emulator would only fix the outbound path
> >>Stefano: Risk would probably go from High/Critical to Low in terms of impact but not remove the issues
> >>Jan: The issue is really with in-guest security issues
> >>Doug: Could we look at QEMU emulator
> >>Andrew: Did this, but does not seem a good enough baseline
> >>James: Have a set of patches which may fix this issue
> >>Jan: Would still not fix in-guest security issues
> >>Andrew: Reduces the severity of XSAs
> >>
> >>Konrad: We still want this?
> >>Jan: If it is doable, then yes ...
> >>Andrew: Huge amount of extra set-up in HV
> >>
> >>ACTION: James to sent patches as RFC to xen-devel@
> >>
> >>Jan: The real issue is the quality and maintainability of emulator code
> >>Konrad: Two paths - emulator code more robust or de-privilege emulator
> >>
> >>
> >>=== x-Splice ===
> >>Konrad: At some point, we can provide catches for which we can create payloads
> >>Konrad: There are areas which are difficult to do, such as patching data
> >>Konrad: Questions - if we had xSplice - should we publish patches to generate the "payload" and as we have in the past
> >>
> >>Andrew: believes that there are only a small number of XSA's that could not easily be changed into payloads
> >>
> >>Agreement: do this as a best-effort
> >>
> >>James: Asks whether chaining patches is an issue
> >>Konrad: No issues, but you should deploy binary patches ...
> >>
> >>Konrad: Can you deploy
> >>Jan: Same as with deploying binaries
> >>Lars: Could just change the boilerplate
> >>
> >>Ross: Is there a way to encode dependencies
> >>Konrad: Yes
> >>
> >>=== Enabling XSM By default ===
> >>Andrew: There are some issues which we need to work through; a lot of little paper cuts
> >>Rich: Could we create a list of issues on the wiki?
> >>Lars: Definitely
> >>Doug: Could we not have a policy which is equivalent to XSM being compiled out
> >>Andrew: Could make policy more modular instead of one big global policy
> >>
> >>Re-apply policy of guest after running
> >>
> >>ACTION: Need a wiki page, Konrad can start one and we can collaboratively flesh it out
> >>Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List
> >>
> >>ACTION: Konrad and others to add detail to it
> >>
> >>
> >It was pointed out to me that I did not get my comments about XSM across
> >clearly. I believe we need to improve the default policy to be
> >equivalent to disabling XSM and/or create a policy called "dummy" that
> >is the same as XSM disabled. To make XSM usage more smooth I propose we
> >bake the default policy into .initdata so that when you boot Xen
> >compiled with XSM you are no worse off than compiling XSM out.
> >
> >The rationale here is that prior to a recent commit when you compiled
> >Xen with XSM enabled but did not provide a default policy then any domUs
> >that you ran had as much access as dom0. The recent commit changed it so
> >that Xen by default does not boot without a policy.
> >
> >With my proposed change we would have "dummy" that would compile in and
> >if you provided another policy it would be used instead or you could
> >late load a replacement policy. Basically filling the gap of turning on
> >XSM and having a system less secure than XSM off until you developed
> >your policy.
> 
> +1.  It also avoids needing to play around loading an extra file as a grub
> module, which makes distro-integration easer.
> 
> ~Andrew

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