Re: [Xen-devel] Granularity of Credit and RTDS Scheduler

[wy11 <wy11@xxxxxxxx>]

Thank you very much for your explanation.

To me, it seems to be an accounting problem because even if the time  
is accounted immediately a VCPU wake up or sleeps, the problem remains  
if the time is recorded in microseconds or million seconds because a  
VCPU can run for less than a unit so that the time accounted is 0.
If the time granularity of RTDS is nanosecond, then it is no longer a  
problem. Can you please help me to know where I can find it in the  
source code?
Again, thanks a lot for your help.

Best Regards,

Wenqiu


Quoting Meng Xu <xumengpanda@xxxxxxxxx>:

> [cc. Dario and George]
>
> On Fri, Jan 6, 2017 at 1:34 PM, wy11 <wy11@xxxxxxxx> wrote:
> > Dear Xen developers,
> Hi,
>
> > Recently I read a paper about possible theft of service attacks in Xen
> > hypervisor.
> >
> > https://arxiv.org/pdf/1103.0759.pdf
> I quickly read it. It is interesting to see that EC2 suffers from such issue.
> According to 4.1, it seems to me that this is more like a scheduler
> "bug" in budget accounting logic.
> When the attack VCPU wake up, the scheduler should starts to counting
> all time consumed from now on for the attack VM, instead of the victim
> VM. When the attack VCPU sleeps, the scheduler should accounts the
> budget consumed for the attack VM.
>
> In the event-driven RTDS scheduler, this issue should not happen. The
> scheduler did account the budget for the correct VMs, IIRC.
> Is there any experiment showing that RTDS scheduler suffers this issue?
>
> > Due to the 10 ms intervals between sampling points, a malicious VM is able
> > to run less than a interval and sleep to avoid being accounted.
> I don't think the scheduling interval is the issue. It is more like a
> budget accounting issue for me.
> Dario and George may have better answer for this.
>
> > According to the info page of RTDS, it seems that after V4.7, a RTDS based
> > scheduler achieves a granularity of microsecond.
> This is just the time granularity for users to specify the VCPU parameters.
> In the scheduler, it is in nanoseconds.
>
> > However, is it able that a
> > VM runs for less than a microsecond and relinquish the host actively so as
> > to keep its budget?
> Nope. I don't think the attack model in the paper will succeed for the
> RTDS scheduler.
> If I understand the attack model correctly, it is the budget
> accounting issue instead of timing granularity issue. (Please correct
> me if I'm wrong).
>
> If you have a script to show the attack on RTDS scheduler, I would be
> happy to reproduce it on my machine and help fix it.
>
> > A similar problem occurs in earlier Linux kernel, and it is fixed in today's
> > Linux on x86 machines by utilizing a clock source TSC with a granularity of
> > nanoseconds. I'd like to know if there is any reason that the Xen hypervisor
> > does not choose a nanosecond scheduler?
> What do you mean by a nanosecond scheduler? In the kernel, scheduler
> accounts the budget in nanoseconds.
>
> Meng
>
>
> --
> -----------
> Meng Xu
> PhD Student in Computer and Information Science
> University of Pennsylvania
> http://www.cis.upenn.edu/~mengxu/
>
> !DSPAM:8895,5871ea96257295422997164!



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