From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [Hackathon 16] Notes from Security Session Date: Tue, 19 Apr 2016 10:02:54 +0100 Message-ID: <5715F43E.7090503@cardoe.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6451800513069904895==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1asRck-0006jd-R9 for xen-devel@lists.xenproject.org; Tue, 19 Apr 2016 09:07:11 +0000 Received: by mail-pf0-f195.google.com with SMTP id r187so1230505pfr.2 for ; Tue, 19 Apr 2016 02:03:10 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Lars Kurth , Xen-devel Cc: James McKenzie , sstabellini@kernel.org, Wei Liu , Ross Philipson , Andrew Cooper , openxt@googlegroups.com, George Dunlap , Rich Persaud , Jan Beulich , Anthony PERARD List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============6451800513069904895== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JPAbVxJHhTWC71sKMfnSPPdKw3iVCjAbc" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JPAbVxJHhTWC71sKMfnSPPdKw3iVCjAbc Content-Type: multipart/mixed; boundary="9oFW0AHc0LpR3w2gcm72qMOg5poDbFToS" From: Doug Goldstein To: Lars Kurth , Xen-devel Cc: George Dunlap , Wei Liu , sstabellini@kernel.org, Andrew Cooper , Konrad Rzeszutek Wilk , Anthony PERARD , Rich Persaud , openxt@googlegroups.com, Jan Beulich , Ross Philipson , James McKenzie Message-ID: <5715F43E.7090503@cardoe.com> Subject: Re: [Hackathon 16] Notes from Security Session References: In-Reply-To: --9oFW0AHc0LpR3w2gcm72qMOg5poDbFToS Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 4/18/16 12:20 PM, Lars Kurth wrote: > Hi all, >=20 > I took notes as much as I could. CC'ed the people who participated most= =2E 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 a= rea. >=20 > Regards > Lars >=20 > =3D=3D Topics discussed =3D=3D > QEMU > De-privilige of QEMU > XSA=20 > x-Splice > x86 Emulator > Enabling XSM By default >=20 > =3D=3D=3D Slimline QEMU =3D=3D=3D >=20 > 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 >=20 > Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU mod= el, 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 ne= eds > Stefano: QEMU does have already a no-default option >=20 > Doug: In the QEMU model: you cannot run a board without a CPU > Doug: KConfig may be acceptable, but re4moving boards may not (initiall= y discussed with Antony L) >=20 > George: Distros don't want to ship two versions of QEMU > George: Compile configurability doesn't help with distros >=20 > Konrad: PVH/HVMLite does not use QEMU (or only as a back) >=20 > Lars: If we had a proposal, working with Intel and the QEMU community, = we could discuss at Xen Summit / KVM Forum is co-located >=20 > James: If we had a future with OVMF, then we probably wouldn't need QEM= U (aka if you want security use PVH with OVMF) > James: Proposal for security conscious applications we could fork and u= se a stubbed out version of QEMU >=20 > Options: > - KConfig > - Run-time disablement=20 > - Xen Summit / KVM Forum > - Intel work / collaboration > - PIX3 > 935 > - OVMF=20 > - Remove xl.cfg (stop configs - in fact we probably only can print a wa= rning "this is not secure and has no security support" or something simil= ar) >=20 > Doug: Issue > - For example Oracle could deal with Config > - BUT, this approach won't work for distros >=20 > ACTION: Konrad is volunteering to drive this discussion >=20 > =3D=3D=3D De-privilige Qemu =3D=3D=3D > 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 d= ormant : QEMU support is there, but Dom0 interface is missing > - Ideas: Do registration in Dom0 > [George has some additional notes] >=20 > 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-ups= tream > Andrew: XS may end up working on this at some undefined point in the fu= ture >=20 > 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=20 > 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) >=20 > ACTION: High;right lack of owner >=20 > Konrad: Seccomp may work=20 > Doug: everything has to be passed as file descriptor=20 >=20 > =3D=3D=3D Narrower XSA Coverage =3D=3D=3D > Jan: XSA 77 (whitelisted a set of dom control and sys control) which ar= e supposedly ... http://xenbits.xen.org/xsa/advisory-77.html=20 > See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Secur= ity 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 =3D> 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 >=20 > Ross Phillipson: Typic ally we have only higher level stuff in a differ= ent xl, but lower level stuff runs on Dom0. So there should be no issue >=20 > George: QEMU stub domains should have security support > George: There are a whole set of other things, which we don't know whet= her they are used > George: Do we want to security support of disaggregated tools-stub >=20 > Agreed: Propose patch to change http://xenbits.xen.org/docs/unstable/mi= sc/xsm-flask.txt on the list > Jan: We can only discuss in public if no issues are pending > Cc: Christopher Clark , Ross Philipson <= ross.philipson@gmail.com>, Daniel Smith > CC the folks on this thread or openxt@googlegroups.com (OpenXT mailing = list)=20 >=20 > =3D=3D=3D x86 Emulation de-privilige =3D=3D=3D > 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 i= mpact 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 >=20 > Konrad: We still want this? > Jan: If it is doable, then yes ... > Andrew: Huge amount of extra set-up in HV >=20 > ACTION: James to sent patches as RFC to xen-devel@ >=20 > Jan: The real issue is the quality and maintainability of emulator code= > Konrad: Two paths - emulator code more robust or de-privilege emulator >=20 >=20 > =3D=3D=3D x-Splice =3D=3D=3D > Konrad: At some point, we can provide catches for which we can create p= ayloads > Konrad: There are areas which are difficult to do, such as patching dat= a > Konrad: Questions - if we had xSplice - should we publish patches to ge= nerate the "payload" and as we have in the past >=20 > Andrew: believes that there are only a small number of XSA's that could= not easily be changed into payloads >=20 > Agreement: do this as a best-effort >=20 > James: Asks whether chaining patches is an issue > Konrad: No issues, but you should deploy binary patches ... >=20 > Konrad: Can you deploy > Jan: Same as with deploying binaries > Lars: Could just change the boilerplate >=20 > Ross: Is there a way to encode dependencies > Konrad: Yes >=20 > =3D=3D=3D Enabling XSM By default =3D=3D=3D > Andrew: There are some issues which we need to work through; a lot of l= ittle 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 compi= led out > Andrew: Could make policy more modular instead of one big global policy= >=20 > Re-apply policy of guest after running >=20 > ACTION: Need a wiki page, Konrad can start one and we can collaborative= ly flesh it out > Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List >=20 > ACTION: Konrad and others to add detail to it=20 >=20 >=20 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. --=20 Doug Goldstein --9oFW0AHc0LpR3w2gcm72qMOg5poDbFToS-- --JPAbVxJHhTWC71sKMfnSPPdKw3iVCjAbc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJXFfRBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUR8kP/jHwLgqd9/MPDwQvDUo30KWp arItSQtJGs2bYlg64V3Z1O1Vt2y25Op4JuQjZYY+IMsyyNsmTKTyIOamJUXzEZtp kQI04x+1G25EbedP9SEQNoBQL5KdeQXkaF0fj0o5gLlVw2c38oA47kC+hkGNPCP9 +4hPmQfypWgOieqbPxH8E1Zc7UQExLdUNh8mNX5bwbYia2uurdvaz+rDG/gtnoLH QAmA3SMeib75PEtusFgMQUN5JLywNUWgjvCqMA2gU9xcD0dh4jK/6dz5ItpJTAy+ hnPz/fVmQsT7rCrjJ6+oxzaneO5QoxeS/RwOjRwyNCDoq6sQzt2pzoP/39Xl+ZEg VRixOrsmsQ8owEgzw/05csbp4LNavu/oj/1I5LSBQH6JfQxPfhfkaaz/f7wNRhFf d7CXy6k49ZS5kyvv9FD63gN38fjrtZQoiPObR4A/8dQi3BgWLca/GZsMdjm/j5N4 06Gm8mPQoSUT/R5Y3VYP/+8oiIdP5kQClgAVkGmhWHuq2agoSbUqxCCf5YeMGYYU wWDr2UOlVaZsThNYHHXuoa6cqcm3mhA1MUHhpYTBnLmuJWXazmU+3QkkX52Rr6Tf mIF7YRw/+5O8/hDE+zzR6RZFAzoyG3BAlb7u9HWaFVSlzkuhitZ77N5foLkX7pxu IqIzhRgU1/g7hcA/Er/P =jG1n -----END PGP SIGNATURE----- --JPAbVxJHhTWC71sKMfnSPPdKw3iVCjAbc-- --===============6451800513069904895== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============6451800513069904895==--