On 11.06.2025 05:13, Jason Andryuk wrote: > On 2025-06-11 09:02, Jan Beulich wrote: >> 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. > > So you are in favor of splitting control and hardware into distinct > sets? I am okay with this. I implemented that originally, but I > started doubting it. Mainly, should control be denied any permission?
Yes, imo: Fundamentally for anything the hardware domain is supposed to be doing. Yet as indicated in other replies to this series - boundaries aren't always as clear as they ought to be for a clean separation. > We aren't using the toolstack to build domains - dom0less or Hyperlaunch > handles that. This avoids issues that might arise from running the > toolstack. IOW you don't have a control domain there in the first place? Jan
