|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Granularity of Credit and RTDS Scheduler
On Tue, Jan 10, 2017 at 4:32 PM, wy11 <wy11@xxxxxxxx> wrote: > 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. Yep. > Can you please help me to know where I can find it in the source > code? It's in burn_budget function in sched_rt.c . > > Again, thanks a lot for your help. :-) Meng > > > 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! > > > > -- ----------- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |