[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 02/17] xsm/silo: Support hardware & xenstore domains
On Wed, 16 Jul 2025, 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. > > 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. > > 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. > > Signed-off-by: Jason Andryuk <jason.andryuk@xxxxxxx> > --- > v2: > Use single evaluate_nospec() for checks. > Remove Control > Add xenstore domain > Expand commit message > Remove always_inline > --- > xen/xsm/silo.c | 15 +++++++++++++-- > 1 file changed, 13 insertions(+), 2 deletions(-) > > diff --git a/xen/xsm/silo.c b/xen/xsm/silo.c > index b89b364287..b392f32507 100644 > --- a/xen/xsm/silo.c > +++ b/xen/xsm/silo.c > @@ -20,6 +20,17 @@ > #define XSM_NO_WRAPPERS > #include <xsm/dummy.h> > > +static bool is_priv_domain(const struct domain *d) > +{ > + /* > + * Open coding of: > + * is_xenstore_domain(d) || is_hardware_domain(d) > + * to place all within one speculative barrier. Please add a comment on why Control Domain, while privileged, is not part of this list > + */ > + return evaluate_nospec((d->options & XEN_DOMCTL_CDF_xs_domain) || > + d == hardware_domain); > +} > + > /* > * Check if inter-domain communication is allowed. > * Return true when pass check. > @@ -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); > } > > static int cf_check silo_evtchn_unbound( > -- > 2.50.0 > >
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |