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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 14/10/16 11:17, Dario Faggioli wrote:
> Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>

We don't have a general framework for declaring things "supported" yet,
and at the moment we only have a single level of "supported", which
includes XSAs.  I do think it makes sense to include an assessment of
the security risk when deciding whether to make such a declaration.

Here's a sort of checklist we could use to start a discussion.

Basically, there are a number of types of security vulnerabilities; we
could ask what the likelihood of any of these happening.

1. Guest -> host privilege escalation.  What functionality do
unprivileged guest have access to --  hypercalls / instructions?  Do
these include any buffers or pointers, and are these handled in a safe
manner -- not only checked, but with a "defensive programming" attitude
in mind?  An informal audit of any such interfaces should generally
suffice to answer this question I think.

2. Guest user -> guest kernel escalation.  Is there functionality
exposed to the guest kernel that must be limited to the kernel?  If so,
is it properly secured from guest user mode?  Might this feature have
any impact on any *other* functionality that the guest kernel uses to
protect itself from the guest user space?

3. Information leakage.  What additional information do the interfaces
expose to anything that has access to them?  Are there any buffers that
may copy hypervisor stack frames, &c?

4. Denial-of-service.  Can anyone use any of the access they have to
crash the hypervisor, or monopolize resources in a way that
significantly impedes the performance of other guests, or other
processes within the same guest?

---

WRT Credit2:

I *think* the only interfaces exposed to *unprivileged* guests are the
SCHEDOP hypercalls -- block(), yield(), &c -- and timers.  (Dario,
please correct me if I'm wrong.)  The only thing that the scheduler
gives is time on the cpu.  Neither block nor yield contain any pointers,
and so it should be trivial to verify that they contain no privilege
escalation paths.

WRT guest user -> guest kernel escalation, the guest kernel is not
relying on anything from the scheduler to protect itself or any data in
any way, so it's difficult to imagine how this might be done.

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.

There have been denial-of-service attacks on credit1 before, where a
vcpu could "game the system" by going to sleep at particular times to
fool the accounting system into thinking that it wasn't running, and
thus run at BOOST priority and monopolize 95% of the cpu.  But this was
fixed by actually charging cpus for time they spent running rather than
probabilistycally, which credit2 already does.

It's worth taking stock again and thinking if there's any way to "game"
credit2 in such a way; but I think it's relatively unlikely that someone
will be able to monopolize the cpu 100% as with the credit1 bug; and
even if it did, it's a pretty low-profile XSA.

So on the whole, I'm inclined to say that from a security perspective,
credit2 is probably OK.  (It would help if Dario filled this out a bit,
I think.)

But I agree with Jan, that such an argument would go well to go in the
commit message. :-)

 -George

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