| Message ID | 5723471702000078000E7283@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
>>> 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) >
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.
>>> 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
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 >
>>> 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
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 >
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>
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
>>> 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
--- 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)