On 16.07.2025 23:14, Jason Andryuk wrote: > Xen includes disctinct concepts of a control domain (privileged) and a > hardware domain, but there is only a single XSM_PRIV check. For dom0 > this is not an issue as they are one and the same. > > With hyperlaunch and its build capabilities, a non-privileged hwdom and a > privileged control domain should be possible. Today the hwdom fails the > XSM_PRIV checks for hardware-related hooks which it should be allowed > access to. > > Introduce XSM_HW_PRIV, and use it to mark many of the physdev_op and > platform_op. The hwdom is allowed access for XSM_HW_PRIV. > > Make XSM_HW_PRIV a new privilege level that is exclusive to the hardware > domain > > A traditional dom0 will be both privileged and hardware domain, so it > continues to have all accesses. > > Why not XSM:Flask? XSM:Flask is fine grain, and this aims to allow > coarse grain. domUs are still domUs. If capabilities are meant to be a > first class citizen, they should be usable by the default XSM policy.
Despite this added paragraph, my prior concern remains of this adding finer granularity than what may be desirable in a coarse-grained world. > @@ -275,7 +279,7 @@ static XSM_INLINE int cf_check xsm_console_io( > if ( cmd == CONSOLEIO_write ) > return xsm_default_action(XSM_HOOK, d, NULL); > #endif > - return xsm_default_action(XSM_PRIV, d, NULL); > + return xsm_default_action(XSM_HW_PRIV, d, NULL); > } This change I'm uncertain about: Why would the control domain not be permitted to interact with the console? It may, in the end, be more important for it to have access than for hwdom. And yes, there is the ->is_console check earlier on. But for the consideration here its presence ought to not matter. Or else the change itself is meaningless (e.g. if we assumed that both would have the flag set). Jan
