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
