Re: Granularity of Credit and RTDS Scheduler

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1962 bytes --]

On Sun, 2017-01-08 at 22:06 +0000, Dario Faggioli wrote:
> Il 08 gen 2017 08:31, Meng Xu <xumengpanda@gmail.com> ha scritto:
> [cc. Dario and George]
> On Fri, Jan 6, 2017 at 1:34 PM, wy11 <wy11@rice.edu> 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. 
>
And it appears I was remembering right. Check commit 
78c9b2a64b38ee72cc4d3ea9e93a1a5d224ed822 "Accurate accounting for
credit scheduler", from George, in August 2009.

The changelog says:

    Rather than debit a full 10ms of credit on a scheduler tick
    (probabilistic), debit credits accurately based on time stamps.
    
    The main problem this is meant to address is an attack on the
    scheduler that allows a rogue guest to avoid ever being debited
    credits.  The basic idea is that the rogue process checks time
    (using rdtsc) periodically, and yields after 9.5ms.  Using this
    technique, a guest can "steal" 95% of the cpu.  This is
    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
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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