Re: [Xen-devel] [PATCH] XSA-77: widen scope again

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
> >>> On 06.05.16 at 16:26, <wei.liu2@xxxxxxxxxx> wrote:
> > On Fri, Apr 29, 2016 at 03:35:51AM -0600, Jan Beulich wrote:
> >> As discussed on the hackathon, avoid us having to issue security
> >> advisories for issues affecting only heavily disaggregated tool stack
> >> setups, which no-one appears to use (or else they should step up to get
> >> things into shape).
> >> 
> >> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> >> ---
> >> As we want to retain supported status of stubdom qemu: Does qemu use
> >> any others when use in a stub domain?
> >> 
> >> --- a/docs/misc/xsm-flask.txt
> >> +++ b/docs/misc/xsm-flask.txt
> >> @@ -59,68 +59,16 @@ http://www.xenproject.org/security-polic 
> >>  
> >>  __HYPERVISOR_domctl (xen/include/public/domctl.h)
> >>  
> >> - The following subops are covered by this statement. subops not listed
> >> - here are considered safe for disaggregation.
> >> + All subops except for the following are covered by this statement.
> > 
> > Since the list is inversed now (subops listed here are safe for
> > disaggregation, correct me if I'm wrong).
> 
> Yes, the sense of the list gets inverted.
> 
> >> - * XEN_DOMCTL_pin_mem_cacheattr
> > 
> > QEMU (stubdom or not) uses this to pin cache attribute of vram. Since we
> > want to support QEMU stubdom, we might want this in the list.
> 
> We'd want this, indeed, but we can't add it right away, as it has
> issues. For one, there's no bounding on the number of ranges
> that may get added (which is relatively easy to deal with; aiui
> qemu really only wants to add a single range). And then there is

Yes, correct.

> the question which trees are really meant to be covered by this
> doc: -unstable has (I hope; would need to be double checked by
> someone) become safe only with commit 0acc7010ac ("x86/HVM:
> honor cache attribute pinning for RAM only", which so far I didn't
> even put on my to-be-backported list), and only when WB is
> being passed as attribute.
> 
> But note that by not having it on the list for now, things don't
> change: As per the original XSA-77, the operation was deemed
> disaggregation unsafe (and hence by implication its use in stub
> domains made stub domains an unsafe / unsupported environment)
> anyway. IOW this consideration is orthogonal to the purpose of
> the patch we're discussing.
> 

Makes sense.

Wei.

> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel