Re: [PATCH 19/23] xsm/dummy: Allow sysctls to both hardware and control

[Jan Beulich <jbeulich@xxxxxxxx>]

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);
>      }
>  }