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?
We aren't using the toolstack to build domains - dom0less or Hyperlaunch
handles that. This avoids issues that might arise from running the
toolstack.
Thanks for your feedback.
-Jason
