From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH] features: declare the Credit2 scheduler as Supported. Date: Tue, 25 Oct 2016 10:18:52 +0200 Message-ID: <1477383532.27407.27.camel@citrix.com> References: <147644021476.15715.14173453351089636671.stgit@Palanthas> <6064e22e-5c72-0b5e-dcde-98252d9a1cc2@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7763376095076994146==" Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bywwv-0003gl-5A for xen-devel@lists.xenproject.org; Tue, 25 Oct 2016 08:19:09 +0000 In-Reply-To: <6064e22e-5c72-0b5e-dcde-98252d9a1cc2@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , xen-devel@lists.xenproject.org Cc: Lars Kurth , Stefano Stabellini , Wei Liu , George Dunlap , Andrew Cooper , Anshul Makkar , Ian Jackson , security@xenproject.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org --===============7763376095076994146== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-/csyw6/3DCvK4ahI4lhF" --=-/csyw6/3DCvK4ahI4lhF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-10-14 at 11:42 +0100, George Dunlap wrote: > On 14/10/16 11:17, Dario Faggioli wrote: > >=20 > > Signed-off-by: Dario Faggioli >=20 > We don't have a general framework for declaring things "supported" > yet, > and at the moment we only have a single level of "supported", which > includes XSAs.=C2=A0=C2=A0I do think it makes sense to include an assess= ment of > the security risk when deciding whether to make such a declaration. >=20 Right... So, first of all, sorry if I dropped the ball on this for a while, but I really wasn't sure of what should have come next (more people from security team speaking their mind? Here or somewhere else? Etc.) As already said by others, it's hard to follow the steps of a procedure which is, in fact, unknown and not formalized nor written down anywhere (which, literally, _just_ mean we need to formalize and write down it! :-D). > Here's a sort of checklist we could use to start a discussion. >=20 Ok, thanks George. I'll go through the checklist, and your analysis of Credit2, and provide my view (when worthwhile). > 1. Guest -> host privilege escalation. > 2. Guest user -> guest kernel escalation. > 3. Information leakage. > 4. Denial-of-service. >=20 > --- >=20 > WRT Credit2: >=20 > I *think* the only interfaces exposed to *unprivileged* guests are > the > SCHEDOP hypercalls -- block(), yield(), &c -- and timers.=C2=A0=C2=A0(Da= rio, > please correct me if I'm wrong.)=C2=A0=C2=A0 > I agree, that's all it's there, especially if we are talking about unprivileged guests. If we include the control domain, we also expose: =C2=A0-=C2=A0XEN_DOMCTL_SCHEDOP_* hypercalls, =C2=A0-=C2=A0XEN_SYSCTL_SCHEDOP_* hypercalls. > The only thing that the scheduler > gives is time on the cpu.=C2=A0=C2=A0Neither block nor yield contain any= > pointers, > and so it should be trivial to verify that they contain no privilege > escalation paths. >=20 I agree. FWIW, I've tried auditing that code, and could not find anything that looks like a potential security issue. E.g., there's not buffer/local variable, being used, that could=20lead to hypervisor stack leaks (and in fact, this is probably more about George's point 3 than 1). > The only information which the scheduler exposes to unprivileged > guests > is the timing information.=C2=A0=C2=A0This may be able to be used for si= de- > channel > attacks to probabilistically infer things about other vcpus running > on > the same system; but this has not traditionally been considered > within > the security boundary. >=20 And this is possible with all schedulers. Not that we can't think of improvements, of course, but if this counts, Credit1 is *Experimental* too. :-) > There have been denial-of-service attacks on credit1 before, where a > vcpu could "game the system" by going to sleep at particular times to > fool the accounting system into thinking that it wasn't running, and > thus run at BOOST priority and monopolize 95% of the cpu.=C2=A0=C2=A0But= this > was > fixed by actually charging cpus for time they spent running rather > than > probabilistycally, which credit2 already does. >=20 And Credit2 does not have BOOST or, said in a more general way, it does not have any way for a vcpu to acquire any kind of "superpowers"... they're all subjected to the same crediting algorithm, which is a lot simpler than Credit1's one, and hence a lot easier to understand, debug and audit. > It's worth taking stock again and thinking if there's any way to > "game" > credit2 in such a way; but I think it's relatively unlikely that > someone > will be able to monopolize the cpu 100% as with the credit1 bug; and > even if it did, it's a pretty low-profile XSA. >=20 It may be me not being a 'security guy' (yet :-)), but I can't think of anything. > But I agree with Jan, that such an argument would go well to go in > the > commit message. :-) >=20 Right. Actually, I wrote a few words about a lot of development and testing having been done lately, and I thought whether or not to use that as commit message. I certainly could have thought about doing something like this that George did, but: =C2=A0- I probably wouldn't have been able to do it as good as him; =C2=A0- I wasn't sure whether it was worth/meaningful for me to do it, as=C2= =A0 =C2=A0 =C2=A0opposed to the security team wanting to do that themselves. So, again, let's formalize the process, because it's hard to follow an unwritten and implicite set of rules. :-) All this being said, what's the next step? Is there anything more I should do, here in this thread? Should we wait for other people to weigh in? Should I resend this patch, with a non empty commit message? Containing what, a summary of this? Any help and insight, would be greatly appreciated. Thanks for everyone's time and Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-/csyw6/3DCvK4ahI4lhF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJYDxVtAAoJEBZCeImluHPuhl8P/R+DI8Fi7gqSmWwhmSmlaFwJ 62XNbBhxYHFIA72PfYsbcqUJAcUdelKtKFwXyWrYWdbMAzPTiqS+yINxDDePkA/k g3tB2mjeE2ElaRLqcy2izvooRDaCnS9fF/LwfJ4X0CD5QMmwcTE0RRnDVt47a/yb uMMt5FqCvQl33pDOEr2BtTxUcW8XY2lTEthLWRbMfwZZSKDv1IXI9mmNwowJ4Nbt 44AM/fp/FpQfRE9uG6glkHagaahQv3pB84kvzheeaWWPGr/rq34Qqw6sBW6ozjpW Q87QmzLs4wZ5yr4f8qsRla5H1LO/gCw63Be07rrbp6ICHVsySgBBQheXtHjKmSJU ufg4o44N6RBCChn+HlpSUCs6SM3qhJVEQDTmoSqD5WGQqV1SSSqLDHhXfWpQ4ydN JA3V/PLu2fC3/omd3M75d+EYtGDy/AnnCOcNc7v01A7XoeQSRGkubXzEXMfRUwPj TUkBR2smBeKLgz5EEfKFPpfc/00ORqJ/M/STKDIFsw6vWdrz0eJJvwzCUdKrgEeA NcxY2PyEo696Zi9Qi1DazaXv0nHvDfJzFJeqGrFCJbaNa9Yu3DwJP/QQgLxNKQMo vpK1qWUmMaRSzKASygVP6+/cDdIAenhsl16vL8Vrkto37KoG5c6tLn6izLCQpDYv 2y3WEQMiyOicBGg7fQqm =oaUz -----END PGP SIGNATURE----- --=-/csyw6/3DCvK4ahI4lhF-- --===============7763376095076994146== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============7763376095076994146==--