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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 11.06.2025 07:08, Jason Andryuk wrote:
> 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.

Yet as indicated in replies to individual patches - the boundaries between
the three aren't clear, which imo goes (to some degree at least) against the
purpose of "disaggregation".

Jan

>  This would be a 
> coarse level of functionality, and Flask would remain for fine-grain and 
> MAC enforcement.
> 
> Regards,
> Jason