On 03/06/2018 06:08 PM, Wei Liu wrote:
> On Tue, Mar 06, 2018 at 05:08:43PM +0000, George Dunlap wrote:
>> We don't promise to protect you against rogue stub domain binaries;
>> only from the running domain once the guest has come up.
>> Signed-off-by: George Dunlap <george.dun...@citrix.com>
>> CC: Ian Jackson <ian.jack...@citrix.com>
>> CC: Wei Liu <wei.l...@citrix.com>
>> CC: Andrew Cooper <andrew.coop...@citrix.com>
>> CC: Jan Beulich <jbeul...@suse.com>
>> CC: Tim Deegan <t...@xen.org>
>> CC: Stefano Stabellini <sstabell...@kernel.org>
>> CC: Konrad Wilk <konrad.w...@oracle.com>
>> CC: Julien Grall <julien.gr...@arm.com>
>> SUPPORT.md | 5 +++++
>> 1 file changed, 5 insertions(+)
>> diff --git a/SUPPORT.md b/SUPPORT.md
>> index a1810b8046..ce9f68e1c2 100644
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -501,6 +501,11 @@ for more information about security support.
>> Status: Supported, with caveats
>> +Only stub domain binaries provided by the host admin
>> +or trusted users are security supported;
> I'm not sure I follow -- why would / should upstream support a binary
> that is not produced from upstream source code?
Hrm, seems I wasn't very clear.
Suppose for some reason, a cloud provider says to their customers, "I'll
let you submit *your own* devicemodel binary! Your virtual guests can
have whatever virtual hardware you can code up! It's secure because it
runs as a stub domain!"
And suppose that we discover a bug in the stubdomain setup code, that
would allow a "crafted image" to break into the toolstack; or we
discovered a bug such that a rogue stubdomain could cause problems after
the stubdomain started but before the guest started. Should we issue an
XSA in that case?
The point of this statement is to say, "No, we would not issue an XSA in
that case: We only provide security support for systems where the
administrator or trusted users provide the stub domain binary; the stub
domain is only meant to protect against attacks *after* the VM has
Does that make sense? It's not saying we don't provide support *for the
binary*; it's saying we don't provide support for *the rest of the
system* if you use an untrusted binary.
Feel free to suggest a reword...
Xen-devel mailing list