Re: [PATCH 2/4] xsm/silo: Support hwdom/control domains

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-06-11 09:17, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
> > In a disaggregated environment, dom0 is split into Control, Hardware,
> > and Xenstore domains, along with domUs.  The is_control_domain() check
> > is not sufficient to handle all these cases.  Add is_priv_domain() to
> > support allowing for the various domains.
> >
> > The purpose of SILO mode is to prevent domUs from interacting with each
> > other.  But dom0 was allowed to communicate with domUs to provide
> > services.  As the disaggregation of dom0, Control, Hardware and Xenstore
> > are all service domains that need to communicate with other domains.
> >
> > To provide xenstore connections, the Xenstore domain must be allowed to
> > connect via grants and event channels.  Xenstore domain must also be
> > allowed to connect to Control and Hardware to provide xenstore to them.
> Are you suggesting that SILO at present is incompatible with a Xenstore
> domain? silo_mode_dom_check() in its original form has no special
> precautions, after all.
Yes, it is incompatible with the current silo_mode_dom_check().  Only 
Control domain is allowed to use grants and event channels with a domU. 
A Xenstore domain would be denied.
Xenstore stubdom only exists for x86 today.  My limited attempts to run 
xenstored in an dedicated Xenstore ARM Linux domain have failed.
> > Hardware domain will provide PV devices to domains, so it must be
> > allowed to connect to domains.
> As a built-in policy, isn't this already going too far? There could
> conceivably be configurations with only pass-through devices in use, in
> which case neither grants nor the event channels operations intercepted
> by SILO would be required.
Such a domain wouldn't have any PV devices configured?  I don't think 
this changes anything compared to today.
Both sides need to be configured and opt-in.  Hardware is a system 
domain, so it should be possible to allow grants and event channels. 
But they won't be used unless configured.
> > That leaves Control.  Xenstore and Hardware would already allow access
> > to Control, so it can obtain services that way.  Control should be
> > "privileged", which would mean it can make the connections.  But with
> > Xenstore and Hardware providing their services to domUs, there may not
> > be a reason to allow Control to use grants or event channels with domUs.
> > Still, Control is privileged, so it should be allowed to do something if
> > it chooses.  Establishing a grant, or event channel requires action on
> > both sides, so allow for the possibility.  This does open up an argo
> > wildcard ring from domUs, FWIW.
> Along the lines of my reply to patch 1, I think Hardware and Control
> need to have a pretty strong boundary between them. It's hard to see,
> for example, whether grant map/copy/transfer would indeed make sense
> between the two.
The Hardware domain might provide a PV device to Control?

I've tested removing control:
static bool is_priv_domain(const struct domain *d)
{
    return is_xenstore_domain(d) || is_hardware_domain(d);
}

And that works in my limited ARM dom0less testing.  The toolstack isn't 
really exercised in that case.  It seems strange that the privileged 
control domain is *not* allowed though.
> Similarly I'm not convinced a strong boundary isn't also needed
> between Xenstore and Hardware.
If hardware is providing PV devices to domains, it will need access to 
Xenstore.  I don't see how you can get around it.
I tried to explain this in the first paragraph.  SILO's purpose was to 
isolate domUs from each other, but allow it to access dom0.  dom0 
embodies the control, hardware, and xenstore capabilities.  So as a 
first approximation, each of Control, Hardware, and Xenstore should be 
allowed to communicate with domUs.
domUs needs to communicate with Xenstore and Hardware for PV devices.

Xenstore provides Xenstore access to Hardware.

Control would want Xenstore access.

I don't know if this helps, but here's a table:

    | CTL | HW  | XS  | domU
----------------------------
CTL |     |  ?  |  y  |  ?
HW  |  ?  |     |  y  |  y
XS  |  y  |  y  |     |  y
domU|  ?  |  y  |  y  |  x

Control and Hardware would be y if we allow PV devices

Control and domUs - I don't have an immediate rational for them.  Except 
that Control is privileged.  I've been running xenconsoled in Hardware. 
If xenconsoled is in Control, then access would be required.
> > --- a/xen/xsm/silo.c
> > +++ b/xen/xsm/silo.c
> > @@ -20,6 +20,12 @@
> >   #define XSM_NO_WRAPPERS
> >   #include <xsm/dummy.h>
> >   
> > +static bool is_priv_domain(const struct domain *d)
> > +{
> > +    return is_xenstore_domain(d) || is_hardware_domain(d) ||
> > +           is_control_domain(d);
> > +}
> This construct expands to two evaluate_nospec(), which likely isn't
> wanted. Some open-coding may be pretty much unavoidable here.
Thanks, yes, good point.

> (I'm
> surprised it's not three, i.e. I find it odd that is_xenstore_domain()
> doesn't also use that guard.)
It looks okay to me.  There were only 2 uses until I added a 3rd in the 
dom0less code.  The XSM check has evaluate_nospec() and the other 2 uses 
aren't security critical - Setting a domain info flag, and __init code 
for dom0less.  Maybe moving the evaluate_nospec() would be safer in case 
use grows in the future, but it looks okay to me today.
Regards,
Jason