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.
> 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.
> 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.
Similarly I'm not convinced a strong boundary isn't also needed
between Xenstore and Hardware.
> --- 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. (I'm
surprised it's not three, i.e. I find it odd that is_xenstore_domain()
doesn't also use that guard.)
Jan
