Re: [PATCH v2 02/17] xsm/silo: Support hardware & xenstore domains

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-07-30 06:17, Jan Beulich wrote:
> On 16.07.2025 23:14, Jason Andryuk wrote:
> > In a disaggregated environment, dom0 is split into Control, Hardware,
> > and Xenstore domains, along with domUs.
> Here we are with terminology again. In a truly disaggregated env, yet
> more (service) domains would come into play. What you mean here is
> only coarse disaggregation, as you're trying to get away without using
> Flask.
If disaggregation only means, fine grain disaggregation, then I'm not 
sure how to differentiate coarse.  I could write "split control and 
hardware domain".
> >   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.
> >
> > 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.
> >
> > Hardware domain will provide PV devices to domains, so it must be
> > allowed to connect to domains.
> >
> > 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.
> "may not be" is too weak for my taste to forbid such.
I can't come up with a concrete example of why Control needs to directly 
communicate with a domU.  Originally I allowed it, but it was your 
previous feedback which made me remove Control.
I don't have a strong opinion on the handling of Control.  I can see it 
argued either way.
> > This silo check is for grants, event channels and argo.  The dummy
> > policy handles other calls, so Hardware is prevented from foreign
> > mapping Control's memory with that.
> By "foreign mapping" you only mean what would result in p2m_foreign
> entries? But grant mapping is okay?
Yes, "foreign mapping" = p2m_foreign.

Using grants requires explicit actions on both sides. 
silo_mode_dom_check() passing still requires action by both sides to 
establish a communication channel.
This is different from a foreign mapping, which is a unilateral action 
by the privileged side.
My intent was to highlight that allowing hardware domain to pass the 
silo_mode_dom_check() does not grant additional is_privilege permissions.
> > @@ -29,8 +40,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);
> >   }
> IOW we're turning by 180°? Interesting ...
While the previous code is written "is_control_domain()" its use in silo 
mode is really "is_dom0()".
(Working on this, I've been thinking about how dom0 is like the god 
Janus with two faces.  A single entity with two faces.  We use 
is_control_domain() and is_hardware_domain(), but often it is just a 
different name for the single dom0)
As stated above, domU <-> Xenstore and domU <-> Hardware (for PV 
devices) are needed to allow those services.  So while it looks like a 
180°, maybe is_control_domain() was the wrong name for dom0?
Regards,
Jason