Re: [PATCH 1/4] xen/xsm: Add XSM_HW_PRIV

[Jason Andryuk <jason.andryuk@xxxxxxx>]

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