[PATCH] XSA-77: widen scope again

[PATCH] XSA-77: widen scope again

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 2774 bytes --]

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@suse.com>
---
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.
 
- * XEN_DOMCTL_createdomain
- * XEN_DOMCTL_destroydomain
- * XEN_DOMCTL_getmemlist
- * XEN_DOMCTL_setvcpuaffinity
- * XEN_DOMCTL_shadow_op
- * XEN_DOMCTL_max_mem
- * XEN_DOMCTL_setvcpucontext
- * XEN_DOMCTL_getvcpucontext
- * XEN_DOMCTL_max_vcpus
- * XEN_DOMCTL_scheduler_op
- * XEN_DOMCTL_iomem_permission
- * XEN_DOMCTL_gethvmcontext
- * XEN_DOMCTL_sethvmcontext
- * XEN_DOMCTL_set_address_size
- * XEN_DOMCTL_assign_device
- * XEN_DOMCTL_pin_mem_cacheattr
- * XEN_DOMCTL_set_ext_vcpucontext
- * XEN_DOMCTL_get_ext_vcpucontext
- * XEN_DOMCTL_test_assign_device
- * XEN_DOMCTL_set_target
- * XEN_DOMCTL_deassign_device
- * XEN_DOMCTL_get_device_group
- * XEN_DOMCTL_set_machine_address_size
- * XEN_DOMCTL_debug_op
- * XEN_DOMCTL_gethvmcontext_partial
- * XEN_DOMCTL_vm_event_op
- * XEN_DOMCTL_mem_sharing_op
- * XEN_DOMCTL_setvcpuextstate
- * XEN_DOMCTL_getvcpuextstate
- * XEN_DOMCTL_set_access_required
- * XEN_DOMCTL_set_virq_handler
- * XEN_DOMCTL_set_broken_page_p2m
- * XEN_DOMCTL_setnodeaffinity
- * XEN_DOMCTL_gdbsx_guestmemio
+ * XEN_DOMCTL_ioport_mapping
+ * XEN_DOMCTL_memory_mapping
+ * XEN_DOMCTL_bind_pt_irq
+ * XEN_DOMCTL_unbind_pt_irq
 
 __HYPERVISOR_sysctl (xen/include/public/sysctl.h)
 
- The following subops are covered by this statement. subops not listed
- here are considered safe for disaggregation.
-
- * XEN_SYSCTL_readconsole
- * XEN_SYSCTL_tbuf_op
- * XEN_SYSCTL_physinfo
- * XEN_SYSCTL_sched_id
- * XEN_SYSCTL_perfc_op
- * XEN_SYSCTL_getdomaininfolist
- * XEN_SYSCTL_debug_keys
- * XEN_SYSCTL_getcpuinfo
- * XEN_SYSCTL_availheap
- * XEN_SYSCTL_get_pmstat
- * XEN_SYSCTL_cpu_hotplug
- * XEN_SYSCTL_pm_op
- * XEN_SYSCTL_page_offline_op
- * XEN_SYSCTL_lockprof_op
- * XEN_SYSCTL_cputopoinfo
- * XEN_SYSCTL_numainfo
- * XEN_SYSCTL_cpupool_op
- * XEN_SYSCTL_scheduler_op
- * XEN_SYSCTL_coverage_op
+ All subops are covered by this statement.
 
 __HYPERVISOR_memory_op (xen/include/public/memory.h)
 




[-- Attachment #2: xsa77-addendum.patch --]
[-- Type: text/plain, Size: 2796 bytes --]

XSA-77: widen scope again

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@suse.com>
---
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.
 
- * XEN_DOMCTL_createdomain
- * XEN_DOMCTL_destroydomain
- * XEN_DOMCTL_getmemlist
- * XEN_DOMCTL_setvcpuaffinity
- * XEN_DOMCTL_shadow_op
- * XEN_DOMCTL_max_mem
- * XEN_DOMCTL_setvcpucontext
- * XEN_DOMCTL_getvcpucontext
- * XEN_DOMCTL_max_vcpus
- * XEN_DOMCTL_scheduler_op
- * XEN_DOMCTL_iomem_permission
- * XEN_DOMCTL_gethvmcontext
- * XEN_DOMCTL_sethvmcontext
- * XEN_DOMCTL_set_address_size
- * XEN_DOMCTL_assign_device
- * XEN_DOMCTL_pin_mem_cacheattr
- * XEN_DOMCTL_set_ext_vcpucontext
- * XEN_DOMCTL_get_ext_vcpucontext
- * XEN_DOMCTL_test_assign_device
- * XEN_DOMCTL_set_target
- * XEN_DOMCTL_deassign_device
- * XEN_DOMCTL_get_device_group
- * XEN_DOMCTL_set_machine_address_size
- * XEN_DOMCTL_debug_op
- * XEN_DOMCTL_gethvmcontext_partial
- * XEN_DOMCTL_vm_event_op
- * XEN_DOMCTL_mem_sharing_op
- * XEN_DOMCTL_setvcpuextstate
- * XEN_DOMCTL_getvcpuextstate
- * XEN_DOMCTL_set_access_required
- * XEN_DOMCTL_set_virq_handler
- * XEN_DOMCTL_set_broken_page_p2m
- * XEN_DOMCTL_setnodeaffinity
- * XEN_DOMCTL_gdbsx_guestmemio
+ * XEN_DOMCTL_ioport_mapping
+ * XEN_DOMCTL_memory_mapping
+ * XEN_DOMCTL_bind_pt_irq
+ * XEN_DOMCTL_unbind_pt_irq
 
 __HYPERVISOR_sysctl (xen/include/public/sysctl.h)
 
- The following subops are covered by this statement. subops not listed
- here are considered safe for disaggregation.
-
- * XEN_SYSCTL_readconsole
- * XEN_SYSCTL_tbuf_op
- * XEN_SYSCTL_physinfo
- * XEN_SYSCTL_sched_id
- * XEN_SYSCTL_perfc_op
- * XEN_SYSCTL_getdomaininfolist
- * XEN_SYSCTL_debug_keys
- * XEN_SYSCTL_getcpuinfo
- * XEN_SYSCTL_availheap
- * XEN_SYSCTL_get_pmstat
- * XEN_SYSCTL_cpu_hotplug
- * XEN_SYSCTL_pm_op
- * XEN_SYSCTL_page_offline_op
- * XEN_SYSCTL_lockprof_op
- * XEN_SYSCTL_cputopoinfo
- * XEN_SYSCTL_numainfo
- * XEN_SYSCTL_cpupool_op
- * XEN_SYSCTL_scheduler_op
- * XEN_SYSCTL_coverage_op
+ All subops are covered by this statement.
 
 __HYPERVISOR_memory_op (xen/include/public/memory.h)
 

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Ping: [PATCH] XSA-77: widen scope again

[Jan Beulich]

>>> On 29.04.16 at 11:35, <JBeulich@suse.com> 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@suse.com>

Ping?

> ---
> 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.
>  
> - * XEN_DOMCTL_createdomain
> - * XEN_DOMCTL_destroydomain
> - * XEN_DOMCTL_getmemlist
> - * XEN_DOMCTL_setvcpuaffinity
> - * XEN_DOMCTL_shadow_op
> - * XEN_DOMCTL_max_mem
> - * XEN_DOMCTL_setvcpucontext
> - * XEN_DOMCTL_getvcpucontext
> - * XEN_DOMCTL_max_vcpus
> - * XEN_DOMCTL_scheduler_op
> - * XEN_DOMCTL_iomem_permission
> - * XEN_DOMCTL_gethvmcontext
> - * XEN_DOMCTL_sethvmcontext
> - * XEN_DOMCTL_set_address_size
> - * XEN_DOMCTL_assign_device
> - * XEN_DOMCTL_pin_mem_cacheattr
> - * XEN_DOMCTL_set_ext_vcpucontext
> - * XEN_DOMCTL_get_ext_vcpucontext
> - * XEN_DOMCTL_test_assign_device
> - * XEN_DOMCTL_set_target
> - * XEN_DOMCTL_deassign_device
> - * XEN_DOMCTL_get_device_group
> - * XEN_DOMCTL_set_machine_address_size
> - * XEN_DOMCTL_debug_op
> - * XEN_DOMCTL_gethvmcontext_partial
> - * XEN_DOMCTL_vm_event_op
> - * XEN_DOMCTL_mem_sharing_op
> - * XEN_DOMCTL_setvcpuextstate
> - * XEN_DOMCTL_getvcpuextstate
> - * XEN_DOMCTL_set_access_required
> - * XEN_DOMCTL_set_virq_handler
> - * XEN_DOMCTL_set_broken_page_p2m
> - * XEN_DOMCTL_setnodeaffinity
> - * XEN_DOMCTL_gdbsx_guestmemio
> + * XEN_DOMCTL_ioport_mapping
> + * XEN_DOMCTL_memory_mapping
> + * XEN_DOMCTL_bind_pt_irq
> + * XEN_DOMCTL_unbind_pt_irq
>  
>  __HYPERVISOR_sysctl (xen/include/public/sysctl.h)
>  
> - The following subops are covered by this statement. subops not listed
> - here are considered safe for disaggregation.
> -
> - * XEN_SYSCTL_readconsole
> - * XEN_SYSCTL_tbuf_op
> - * XEN_SYSCTL_physinfo
> - * XEN_SYSCTL_sched_id
> - * XEN_SYSCTL_perfc_op
> - * XEN_SYSCTL_getdomaininfolist
> - * XEN_SYSCTL_debug_keys
> - * XEN_SYSCTL_getcpuinfo
> - * XEN_SYSCTL_availheap
> - * XEN_SYSCTL_get_pmstat
> - * XEN_SYSCTL_cpu_hotplug
> - * XEN_SYSCTL_pm_op
> - * XEN_SYSCTL_page_offline_op
> - * XEN_SYSCTL_lockprof_op
> - * XEN_SYSCTL_cputopoinfo
> - * XEN_SYSCTL_numainfo
> - * XEN_SYSCTL_cpupool_op
> - * XEN_SYSCTL_scheduler_op
> - * XEN_SYSCTL_coverage_op
> + All subops are covered by this statement.
>  
>  __HYPERVISOR_memory_op (xen/include/public/memory.h)
>  




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

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

[Wei Liu]

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@suse.com>
> ---
> 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).

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

Wei.

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

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

[Jan Beulich]

>>> On 06.05.16 at 16:26, <wei.liu2@citrix.com> 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@suse.com>
>> ---
>> 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@lists.xen.org
http://lists.xen.org/xen-devel

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

[Wei Liu]

On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
> >>> On 06.05.16 at 16:26, <wei.liu2@citrix.com> 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@suse.com>
> >> ---
> >> 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@lists.xen.org
http://lists.xen.org/xen-devel

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

[Jan Beulich]

>>> On 09.05.16 at 12:56, <wei.liu2@citrix.com> wrote:
> On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
>> 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.

May I translate this into an ack? Or would you prefer for it to be
acked a security team member?

Jan


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

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

[Wei Liu]

On Mon, May 09, 2016 at 05:18:33AM -0600, Jan Beulich wrote:
> >>> On 09.05.16 at 12:56, <wei.liu2@citrix.com> wrote:
> > On Mon, May 09, 2016 at 03:31:52AM -0600, Jan Beulich wrote:
> >> 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.
> 
> May I translate this into an ack? Or would you prefer for it to be
> acked a security team member?
> 

The latter. I think it is more appropriate for a security team member to
ack this patch.

Wei.

> Jan
> 

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

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

[Andrew Cooper]

On 29/04/16 10:35, 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@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

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

Re: Ping: [PATCH] XSA-77: widen scope again

[George Dunlap]

On 06/05/16 09:12, Jan Beulich wrote:
>>>> On 29.04.16 at 11:35, <JBeulich@suse.com> 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@suse.com>
> 
> Ping?
> 
>> ---
>> 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.

Sorry I'm just getting to this -- I think the wording is a bit unclear here.

The previous wording made it clear what "covered by this statement"
means -- i.e., "subops not listed here are considered safe for
disaggregation".

Maybe something like this:

"All subops except the following are covered by this statement.  (That
is, only the subops below are considered safe for disaggregation.)"

>>  
>> - * XEN_DOMCTL_createdomain
>> - * XEN_DOMCTL_destroydomain
>> - * XEN_DOMCTL_getmemlist
>> - * XEN_DOMCTL_setvcpuaffinity
>> - * XEN_DOMCTL_shadow_op
>> - * XEN_DOMCTL_max_mem
>> - * XEN_DOMCTL_setvcpucontext
>> - * XEN_DOMCTL_getvcpucontext
>> - * XEN_DOMCTL_max_vcpus
>> - * XEN_DOMCTL_scheduler_op
>> - * XEN_DOMCTL_iomem_permission
>> - * XEN_DOMCTL_gethvmcontext
>> - * XEN_DOMCTL_sethvmcontext
>> - * XEN_DOMCTL_set_address_size
>> - * XEN_DOMCTL_assign_device
>> - * XEN_DOMCTL_pin_mem_cacheattr
>> - * XEN_DOMCTL_set_ext_vcpucontext
>> - * XEN_DOMCTL_get_ext_vcpucontext
>> - * XEN_DOMCTL_test_assign_device
>> - * XEN_DOMCTL_set_target
>> - * XEN_DOMCTL_deassign_device
>> - * XEN_DOMCTL_get_device_group
>> - * XEN_DOMCTL_set_machine_address_size
>> - * XEN_DOMCTL_debug_op
>> - * XEN_DOMCTL_gethvmcontext_partial
>> - * XEN_DOMCTL_vm_event_op
>> - * XEN_DOMCTL_mem_sharing_op
>> - * XEN_DOMCTL_setvcpuextstate
>> - * XEN_DOMCTL_getvcpuextstate
>> - * XEN_DOMCTL_set_access_required
>> - * XEN_DOMCTL_set_virq_handler
>> - * XEN_DOMCTL_set_broken_page_p2m
>> - * XEN_DOMCTL_setnodeaffinity
>> - * XEN_DOMCTL_gdbsx_guestmemio
>> + * XEN_DOMCTL_ioport_mapping
>> + * XEN_DOMCTL_memory_mapping
>> + * XEN_DOMCTL_bind_pt_irq
>> + * XEN_DOMCTL_unbind_pt_irq
>>  
>>  __HYPERVISOR_sysctl (xen/include/public/sysctl.h)
>>  
>> - The following subops are covered by this statement. subops not listed
>> - here are considered safe for disaggregation.
>> -
>> - * XEN_SYSCTL_readconsole
>> - * XEN_SYSCTL_tbuf_op
>> - * XEN_SYSCTL_physinfo
>> - * XEN_SYSCTL_sched_id
>> - * XEN_SYSCTL_perfc_op
>> - * XEN_SYSCTL_getdomaininfolist
>> - * XEN_SYSCTL_debug_keys
>> - * XEN_SYSCTL_getcpuinfo
>> - * XEN_SYSCTL_availheap
>> - * XEN_SYSCTL_get_pmstat
>> - * XEN_SYSCTL_cpu_hotplug
>> - * XEN_SYSCTL_pm_op
>> - * XEN_SYSCTL_page_offline_op
>> - * XEN_SYSCTL_lockprof_op
>> - * XEN_SYSCTL_cputopoinfo
>> - * XEN_SYSCTL_numainfo
>> - * XEN_SYSCTL_cpupool_op
>> - * XEN_SYSCTL_scheduler_op
>> - * XEN_SYSCTL_coverage_op
>> + All subops are covered by this statement.

"... (That is, no subops are considered safe for disaggregation.)"

 -George

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

Re: Ping: [PATCH] XSA-77: widen scope again

[Jan Beulich]

>>> On 09.05.16 at 18:19, <george.dunlap@citrix.com> wrote:
> On 06/05/16 09:12, Jan Beulich wrote:
>>>>> On 29.04.16 at 11:35, <JBeulich@suse.com> 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@suse.com>
>> 
>> Ping?
>> 
>>> ---
>>> 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.
> 
> Sorry I'm just getting to this -- I think the wording is a bit unclear here.
> 
> The previous wording made it clear what "covered by this statement"
> means -- i.e., "subops not listed here are considered safe for
> disaggregation".
> 
> Maybe something like this:
> 
> "All subops except the following are covered by this statement.  (That
> is, only the subops below are considered safe for disaggregation.)"

Well, I can certainly do this, but to me it states the same thing twice.

Jan


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