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