The is_control_domain() check is not sufficient for a split
hardware/control domain.  Add is_priv_domain() to support allowing for
either control or hardware.

Without this, a xenstore/hardware domain is unable to map a domU's
grants.

This silo check is for grants, events and argo.  The dummy policy
handles other calls, so hardware is prevented from foreign mapping
control's memory with that.

This would need to be expanded for a standalone Xenstore domain.

Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>
---
 xen/xsm/silo.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c
index b89b364287..d5e1a554ea 100644
--- a/xen/xsm/silo.c
+++ b/xen/xsm/silo.c
@@ -20,6 +20,11 @@
 #define XSM_NO_WRAPPERS
 #include <xsm/dummy.h>
 
+static always_inline bool is_priv_domain(const struct domain *d)
+{
+    return is_control_domain(d) || is_hardware_domain(d);
+}
+
 /*
  * Check if inter-domain communication is allowed.
  * Return true when pass check.
@@ -29,8 +34,8 @@ static bool silo_mode_dom_check(const struct domain *ldom,
 {
     const struct domain *currd = current->domain;
 
-    return (is_control_domain(currd) || is_control_domain(ldom) ||
-            is_control_domain(rdom) || ldom == rdom);
+    return (is_priv_domain(currd) || is_priv_domain(ldom) ||
+            is_priv_domain(rdom) || ldom == rdom);
 }
 
 static int cf_check silo_evtchn_unbound(
-- 
2.48.1

On 06.03.2025 23:03, Jason Andryuk wrote:
> The is_control_domain() check is not sufficient for a split
> hardware/control domain.  Add is_priv_domain() to support allowing for
> either control or hardware.
> 
> Without this, a xenstore/hardware domain is unable to map a domU's
> grants.
> 
> This silo check is for grants, events and argo.  The dummy policy
> handles other calls, so hardware is prevented from foreign mapping
> control's memory with that.
> 
> This would need to be expanded for a standalone Xenstore domain.
> 
> Signed-off-by: Jason Andryuk <jason.andryuk@amd.com>

I think what first needs spelling out is what the function of SILO is
when it comes to specifically the control and hardware domains. Should
the two be able to communicate? The answer isn't obviously "yes" imo.
Yet if it isn't, ...

> --- a/xen/xsm/silo.c
> +++ b/xen/xsm/silo.c
> @@ -20,6 +20,11 @@
>  #define XSM_NO_WRAPPERS
>  #include <xsm/dummy.h>
>  
> +static always_inline bool is_priv_domain(const struct domain *d)

(Side note: I don't think always_inline is warranted here. Even inline
we prefer to only put on functions defined in headers.)

> +{
> +    return is_control_domain(d) || is_hardware_domain(d);
> +}
> +
>  /*
>   * Check if inter-domain communication is allowed.
>   * Return true when pass check.
> @@ -29,8 +34,8 @@ static bool silo_mode_dom_check(const struct domain *ldom,
>  {
>      const struct domain *currd = current->domain;
>  
> -    return (is_control_domain(currd) || is_control_domain(ldom) ||
> -            is_control_domain(rdom) || ldom == rdom);
> +    return (is_priv_domain(currd) || is_priv_domain(ldom) ||
> +            is_priv_domain(rdom) || ldom == rdom);
>  }

... this would end up being overly lax.

Jan