The Control domain is denied access to an untargetable domain.  However
init-dom0less wants to read the xenstore event channel HVM param to
determine if xenstore should be set up.

This is a read operation, so it is not modifying the domain.  Special
case the HVMOP_get_param operation for is_control_domain().  It is done
in xsm_hvm_param() because xsm_default_action() is too complicated.
HVMOP_get_param should be allowed for a domain itself (XSM_TARGET) and
its device model - src->target or is_dm_domain().  It should otherwise
be denied for untargetable domains.  xsm_default_action() doesn't have
sufficient information to identify the particular operation, so put it
in xsm_hvm_param().

Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
It's messy, but I couldn't think of a better way.
---
 xen/include/xsm/dummy.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index 4d7b1d61eb..896ebee631 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -621,7 +621,10 @@ static XSM_INLINE int cf_check xsm_hvm_param(
     XSM_DEFAULT_ARG struct domain *d, unsigned long op)
 {
     XSM_ASSERT_ACTION(XSM_TARGET);
-    return xsm_default_action(action, current->domain, d);
+    /* Special case to allow init-dom0less to read HVM params. */
+    if ( op == HVMOP_get_param && is_control_domain(current->domain) )
+        return 0;
+    return xsm_default_action(XSM_TARGET, current->domain, d);
 }
 
 static XSM_INLINE int cf_check xsm_hvm_param_altp2mhvm(
-- 
2.50.0

On 16.07.2025 23:14, Jason Andryuk wrote:
> The Control domain is denied access to an untargetable domain.  However
> init-dom0less wants to read the xenstore event channel HVM param to
> determine if xenstore should be set up.
> 
> This is a read operation, so it is not modifying the domain.  Special
> case the HVMOP_get_param operation for is_control_domain().  It is done
> in xsm_hvm_param() because xsm_default_action() is too complicated.
> HVMOP_get_param should be allowed for a domain itself (XSM_TARGET) and
> its device model - src->target or is_dm_domain().  It should otherwise
> be denied for untargetable domains.  xsm_default_action() doesn't have
> sufficient information to identify the particular operation, so put it
> in xsm_hvm_param().
> 
> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> It's messy, but I couldn't think of a better way.

Fits well with my remarks on earlier patches. The granularity you want
simply can't be had this way, unless you use such undesirable "overrides".

Jan

On 2025-07-30 11:21, Jan Beulich wrote:
> On 16.07.2025 23:14, Jason Andryuk wrote:
>> The Control domain is denied access to an untargetable domain.  However
>> init-dom0less wants to read the xenstore event channel HVM param to
>> determine if xenstore should be set up.
>>
>> This is a read operation, so it is not modifying the domain.  Special
>> case the HVMOP_get_param operation for is_control_domain().  It is done
>> in xsm_hvm_param() because xsm_default_action() is too complicated.
>> HVMOP_get_param should be allowed for a domain itself (XSM_TARGET) and
>> its device model - src->target or is_dm_domain().  It should otherwise
>> be denied for untargetable domains.  xsm_default_action() doesn't have
>> sufficient information to identify the particular operation, so put it
>> in xsm_hvm_param().
>>
>> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
>> ---
>> It's messy, but I couldn't think of a better way.
> 
> Fits well with my remarks on earlier patches. The granularity you want
> simply can't be had this way, unless you use such undesirable "overrides".

Following Stefano's suggestion, this patch can be dropped.  With 
xenstored auto-introducing predefined domains, init-dom0less can use the 
introduced state to determine which domains to handle.

Regards,
Jason

On Wed, 16 Jul 2025, Jason Andryuk wrote:
> The Control domain is denied access to an untargetable domain.  However
> init-dom0less wants to read the xenstore event channel HVM param to
> determine if xenstore should be set up.

This could be done differently, for instance if xs_is_domain_introduced
returns true, we can assume that xenstore doesn't need to be setup. Then
we don't need to call xc_hvm_param_get. At that point we don't need this
patch?





> This is a read operation, so it is not modifying the domain.  Special
> case the HVMOP_get_param operation for is_control_domain().  It is done
> in xsm_hvm_param() because xsm_default_action() is too complicated.
> HVMOP_get_param should be allowed for a domain itself (XSM_TARGET) and
> its device model - src->target or is_dm_domain().  It should otherwise
> be denied for untargetable domains.  xsm_default_action() doesn't have
> sufficient information to identify the particular operation, so put it
> in xsm_hvm_param().
> 
> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
> ---
> It's messy, but I couldn't think of a better way.
> ---
>  xen/include/xsm/dummy.h | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
> index 4d7b1d61eb..896ebee631 100644
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -621,7 +621,10 @@ static XSM_INLINE int cf_check xsm_hvm_param(
>      XSM_DEFAULT_ARG struct domain *d, unsigned long op)
>  {
>      XSM_ASSERT_ACTION(XSM_TARGET);
> -    return xsm_default_action(action, current->domain, d);
> +    /* Special case to allow init-dom0less to read HVM params. */
> +    if ( op == HVMOP_get_param && is_control_domain(current->domain) )
> +        return 0;
> +    return xsm_default_action(XSM_TARGET, current->domain, d);
>  }
>  
>  static XSM_INLINE int cf_check xsm_hvm_param_altp2mhvm(
> -- 
> 2.50.0
> 
>