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

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

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 



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