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

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Mar 06, 2018 at 06:18:12PM +0000, George Dunlap wrote:
> 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.dunlap@xxxxxxxxxx>
> >> ---
> >> CC: Ian Jackson <ian.jackson@xxxxxxxxxx>
> >> CC: Wei Liu <wei.liu2@xxxxxxxxxx>
> >> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> >> CC: Jan Beulich <jbeulich@xxxxxxxx>
> >> CC: Tim Deegan <tim@xxxxxxx>
> >> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> >> CC: Konrad Wilk <konrad.wilk@xxxxxxxxxx>
> >> CC: Julien Grall <julien.grall@xxxxxxx>
> >> ---
> >>  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
> started up."
> 

I think there is too much special-casing here. Stubdom is just another
domain. It should be treated like any untrusted DomU, unless there is
some set of interfaces which is only available to stubdom but not an
ordinary DomU. In this case -- the toolstack code that sets up the
stubdom? Some special xenstore node that only stubdom can read from /
write to?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel