On 2025-06-12 03:36, Jan Beulich wrote:
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.
Ok.
Yet as indicated in other replies to this series - boundaries
aren't always as clear as they ought to be for a clean separation.
Agreed.
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?
I have a domain with d->is_privileged == true. We don't create more
domains with it though, which was your other email's definition of the
control domain. But it can pause and unpause domains.
Regards,
Jason
