Re: [Xen-devel] [Hackathon 16] Notes from Security Session

[Doug Goldstein <cardoe@xxxxxxxxxx>]

On 4/18/16 12:20 PM, Lars Kurth wrote:
> Hi all,
> 
> 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@xxxxxxxxx>, Ross Philipson 
> <ross.philipson@xxxxxxxxx>, Daniel Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> CC the folks on this thread or openxt@xxxxxxxxxxxxxxxx (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.

-- 
Doug Goldstein

Attachment: signature.asc
Description: OpenPGP digital signature

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