On 11.06.2025 00:57, 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 given to the hardware > domain, but is not exclusive. The control domain can still execute > XSM_HW_PRIV commands. This is a little questionable since it's unclear > how the control domain can meaningfully execute them. But this approach > is chosen to maintain the increasing privileges and keep control domain > fully privileged.
I consider this conceptually wrong. "Control" aiui refers to software (e.g. VMs or system-wide settings), but there ought to be a (pretty?) clear boundary between control and hardware domains, imo. As to "pretty" - should any overlap be necessary (xms_machine_memory_map() comes to mind), such would need handling specially then, I think. At the same time: The more of an overlap there is, the less clear it is why the two want/need separating in the first place. Jan
