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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan


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