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

[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/

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