On 06.03.2025 23:03, Jason Andryuk wrote: > xl queries SYSCTL_physinfo for the physical cpus: > domU:~# xl list > libxl: error: libxl_utils.c:817:libxl_cpu_bitmap_alloc: failed to retrieve > the maximum number of cpus > libxl: error: libxl_utils.c:817:libxl_cpu_bitmap_alloc: failed to retrieve > the maximum number of cpus > libxl: error: libxl_utils.c:817:libxl_cpu_bitmap_alloc: failed to retrieve > the maximum number of cpus > Name ID Mem VCPUs State Time(s) > Domain-0 0 800 1 r----- 130.0 > dom0less-1 1 400 1 r----- 130.3 > dom0less-2 2 800 1 r----- 130.3 > > Hardware and control are both privileged. Allow them both access to > sysctls so they have insight into the running system. This is coarse > grained permissions for the dummy policy.
In an earlier patch you alluded to the control domain being guarded against the hardware one. Shouldn't hwdom be limited operations retrieving info, but refused to make any changes to the system? Or maybe some kinds of changes are to be done by hwdom, but then shouldn't be possible to be made by the control domain? > --- a/xen/include/xsm/dummy.h > +++ b/xen/include/xsm/dummy.h > @@ -194,9 +194,10 @@ static XSM_INLINE int cf_check > xsm_sysctl(XSM_DEFAULT_ARG int cmd) > case XEN_SYSCTL_getdomaininfolist: > return xsm_default_action(XSM_XS_PRIV, current->domain, NULL); > case XEN_SYSCTL_readconsole: > - case XEN_SYSCTL_physinfo: Didn't you add this line just a single patch ago? Jan > return xsm_default_action(XSM_HW_PRIV, current->domain, NULL); > default: > + if ( is_hardware_domain(current->domain) ) > + return xsm_default_action(XSM_HW_PRIV, current->domain, NULL); > return xsm_default_action(XSM_PRIV, current->domain, NULL); > } > }
