From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: Granularity of Credit and RTDS Scheduler Date: Fri, 13 Jan 2017 09:37:54 +0100 Message-ID: <1484296674.9947.33.camel@citrix.com> References: <2e72628c-9c49-4c18-b128-befae444e16f@email.android.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1264966664431805866==" Return-path: In-Reply-To: <2e72628c-9c49-4c18-b128-befae444e16f@email.android.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Meng Xu Cc: George Dunlap , wy11 , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org --===============1264966664431805866== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=-d0d1U4w+MqjdBhxf5mA1" --=-d0d1U4w+MqjdBhxf5mA1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2017-01-08 at 22:06 +0000, Dario Faggioli wrote: > Il 08 gen 2017 08:31, Meng Xu ha scritto: > [cc. Dario and George] > On Fri, Jan 6, 2017 at 1:34 PM, wy11 wrote: > > Recently I read a paper about possible theft of service attacks in > Xen > > hypervisor. > > > > https://arxiv.org/pdf/1103.0759.pdf > > IIRC, is that it's a known attack vector and it's been fixed.=20 > And it appears I was remembering right. Check commit=C2=A0 78c9b2a64b38ee72cc4d3ea9e93a1a5d224ed822 "Accurate accounting for credit scheduler", from George, in August 2009. The changelog says: =C2=A0 =C2=A0 Rather than debit a full 10ms of credit on a scheduler tick =C2=A0=C2=A0=C2=A0=C2=A0(probabilistic), debit credits accurately based on = time stamps. =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0The main problem this is meant to address is an att= ack on the =C2=A0=C2=A0=C2=A0=C2=A0scheduler that allows a rogue guest to avoid ever b= eing debited =C2=A0=C2=A0=C2=A0=C2=A0credits.=C2=A0=C2=A0The basic idea is that the rogu= e process checks time =C2=A0 =C2=A0 (using rdtsc) periodically, and yields after 9.5ms.=C2=A0=C2= =A0Using this =C2=A0 =C2=A0 technique, a guest can "steal" 95% of the cpu.=C2=A0=C2=A0Thi= s is =C2=A0 =C2=A0 particularly an issue in cloud environments. So, that's the reaction to exactly the attack vector described in the paper being found and reported, and it closes the hole by precisely accounting how much credits a vCPU consumes. It does it with full nanoseconds granularity, and it does it precisely. So, the final and conclusive answer to your doubt is that _none_ of the existing Xen scheduler (Credit, Credit2 or RTDS) are affected by the problem described in the paper, and you can use whichever one you like, with no fear. :-) Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-d0d1U4w+MqjdBhxf5mA1 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 iQIcBAABCAAGBQJYeJHiAAoJEBZCeImluHPuyZIQAMKqL/LP7JqOcLomXAzWj/0Y ePD+xSjrcPNnBb9L14Ka/IYDdIFSZTuHthSwAuE8ibIRie/1wCeBTqp2CThY2xNa GQHjIE3QTkXcwClgVnUBDx/UyzmXCmjTuxNuAEmYW7K2nYABfgqfc006u3WTXRD8 fMhWAF/sEivCYKgFxTioKruAeTH29UojZh3WHiUQ0RxXjkjCxXb6mapqOWtI/muF eRoyawzjNMIRp5Ku63yGSyRVMaoUevia9LzRs5QWle9xr+gpdjbNIBgdzeG2vkhP jVgnpQNf+DsombMTNHLKDm6cjQdeZKsVma1MLzteohhYPNHAnDhUnjKFb0kk0olc ZX0JEWj0nHTh1yeM40yv2+MnFf2Q+9frUKyFJBLYjI+Z9NLLrpIe3T2vBmqeUcMH jBh657hprPTBMEA4L8WbPTk+3B8P8YWjNFC18lLIAV3U+KVcCZEBv6YKecQgpT3k aQWh1KaE6yf7Opbnt31IXFpfeT3eyBBwDeesqnAYyZmF0NLjFHLcD2UdaQ3/ncRk XsBTWUKSZqYnjkhiuimeK0iFHTaM0XhHpnRvqPQFNxq43X+MzWL3BZcAp5Iyoj1Q SKP5d2m+Fy7iYC+DduUFr9aAFqK7SJrpJg7zzjQLb5h7dzj69BtsKMxmmzD6o1nF /lEU5hb+3lZyJsmlGjpi =xuV6 -----END PGP SIGNATURE----- --=-d0d1U4w+MqjdBhxf5mA1-- --===============1264966664431805866== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============1264966664431805866==--