Re: [PATCH 0/4] XSM changes for split hardware / control domain

[Jason Andryuk <jason.andryuk@xxxxxxx>]

On 2025-06-11 09:28, Jan Beulich wrote:
> On 11.06.2025 00:57, Jason Andryuk wrote:
> > Theses are the broad changes needed for a split hardware / control
> > domain.
> >
> > An earlier posting gave device_model privileges to hardware domain.  For
> > this posting, it was split out into a new capability.  This way the
> > operator can choose where to run the device models without making the
> > hardware domain have the permissions.
> >
> > The first patch add XSM_HW_PRIV for the hardware hypercalls.  Unlike the
> > first posting, the control domain can call these hypercalls even though
> > it doesn't really make sense.  The idea was to keep the control domain
> > all powerful from an XSM perspective.
> >
> > SILO is changed to allow control, hardwware or xenstore to service
> > domUs.  Xenstore and hardware will use grants for PV interfaces.
> > Control wouldn't typically provide PV interfaces to domUs, but it is
> > given the permision to do so.  Again, to keep control all powerful.
> >
> > xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo this is not strictly
> > needed.  xenconsoled could read Xen's dmesg.  If it's in hwdom, then
> > that permission would be required.  SYSCTL_physinfo is mainly to silence
> > xl messages, which are mostly cosmetic.
> >
> > Jason Andryuk (4):
> >    xen/xsm: Add XSM_HW_PRIV
> >    xsm/silo: Support hwdom/control domains
> >    xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model
> >    xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo
> Overall I can't help the impression that this level of disaggregation simply
> requires the use of Flask.
I have thought about that.  The problem with Flask is the complexity of 
the security server.  We don't want to have to deal with all that code. 
A fixed policy is easier for our coverage testing.
Exposing separate control, hardware and xenstore capabilities, it makes 
sense for the default policy to function with them.  This would be a 
coarse level of functionality, and Flask would remain for fine-grain and 
MAC enforcement.
Regards,
Jason