Re: [Xen-devel] [PATCH v3] features: declare the Credit2 scheduler as Supported.

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 02.11.16 at 16:05, <dario.faggioli@xxxxxxxxxx> wrote:
> Credit2 is available in tree as an "Experimental" scheduler since
> a few years. Recently, effort started for making it production ready
> and, eventually, the new Xen's default scheduler. As a consequence of
> that, it has undergone a greatd deal of development, testing and
> benchmarking.
> 
> In fact, Credit2's much more modern (wrt Credit1) design and cleaner
> code makes it a lot easier to understand what the scheduler is doing,
> fix scheduling issues that may come up, and implement new and more
> advanced features, in future.
> 
> In some more details:
> 
>  - key features that were missing (pinning and context switching
>    rate-limiting) have now been implemented, and more (soft affinity,
>    caps and reservations) are about to come. The gap wrt Credit1 is
>    therefore closing. In particular, with pinning and rate-limiting
>    available, the scheduler can be considered usable.
> 
>  - Credit2 is tested by OSSTest since long time. Furthermore, as a
>    part of recent efforts, stress tests and benchmarks have been run
>    and shown no bugs or stability issues.
> 
>  - A number of different benchmarks have been run, most of them
>    comparing Credit2 with Credit1. Some of the results were posted on
>    xen-devel, some others have been illustrated during a talk at 2016
>    edition of Xen-Project Developer Summit. In general, performance
>    look promising --if not better than Credit1 already, in some of
>    the cases.
> 
> It therefore appears that we are ready to mark the Credit2 scheduler
> as a 'Supported' feature, and ask users to look at it and try it, if
> they think it suits their needs.
> 
> Of course, declaring something 'Supported' has security implications.
> So here it is how the situation looks like from a security standpoint:
> 
> 1) Is guest->host privilege escalation possible?
> 
> The only interfaces exposed to unprivileged guests are the SCHEDOP
> hypercalls, and timers. None of those hypercalls contain any pointers,
> and they don't look to contain any privilege escalation path. Also,
> they're not specific to Credit2, as they're "used" by all schedulers
> (ingluding the current default, Credit1), so anything about these
> interfaces would be a security concern already.
> 
> 
> 2) Is guest user->guest kernel escalation possible?
> 
> The guest kernel is not really relying on anything from the scheduler
> to protect itself or any data in any way.
> 
> 
> 3) Is there any information leakage?
> 
> The only information which the scheduler exposes to unprivileged
> guests is the timing information.  This may be able to be used for
> side-channel attacks to probabilistically infer things about other
> vcpus running on the same system; but this has not traditionally
> been considered within the security boundary. And, again, this is
> possible with all schedulers.
> 
> The control domain can issue DOMCTL_SCHEDOP and SYSCTL_SCHEDOP
> hypercalls, but the involved data structures are handled in a
> way that does not leak information (which would be leaked "only"
> to Dom0 anyway).
> 
> 
> 4) Can a Denial-of-Service be triggered?
> 
> This is a risk, with schedulers, and one that's hard to foresee.
> For instance, it _did_ happen on Credit1, in the past (a vcpu
> could "game the system" by sleeping at particular times to gain
> BOOST priority and monopolize 95% of the cpu). In that case, it
> was possible because of the probabilistic nature of accounting
> in Credit1 (which was then fixed). Well, Credit2:
>  - already do accurate, rather than probabilistic, accounting;
>  - does not have any BOOST or, in general, any way for a vcpu to
>    become 'more important' than the others: they're all subjected
>    to the same crediting algorithm.
> 
> Also note that, the accounting and the crediting algorithm are a lot
> simpler than in Credit1, and hence a lot easier to understand, debug
> and audit.
> 
> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

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