[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] SUPPORT.md: Clarify stubdomain support

George Dunlap writes ("Re: [PATCH] SUPPORT.md: Clarify stubdomain support"):
> I think my answer before contains the answer to your question.  Yes, a
> stubdomain *image* has access to code and interfaces that a *running
> stubdomain* does not -- it interacts with the setup code.  Its image is
> parsed by the toolstack, which means that a *hostile image* has
> opportunities to break into the toolstack that a *hostile running
> domain* (i.e., one which became hostile as a result of being exploited)
> does not).  In addition, stub domains starts running before the
> toolstack is completely finished setting up the target VM; if there were
> a race condition somewhere in the setup code, a rogue stubdomain could
> potentially take advantage of this race condition.
> This didn't come out of nowhere.  From the Security Team's perspective,
> the main purpose of SUPPORT.md is to be able to say of a bug, "This is
> not a security issue; we will not issue an XSA."  There was specifically
> an issue for which we didn't want to issue an XSA because it's a
> configuration nobody ever intended on supporting, hence the patch.

I agree with George.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.