|
[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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |