Re: [PATCH 15/23] xen/xsm: Add XSM_HW_PRIV

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 17 Mar 2025, Jason Andryuk wrote:
> On 2025-03-17 10:22, Jan Beulich wrote:
> > On 06.03.2025 23:03, Jason Andryuk wrote:
> > > --- a/xen/include/xsm/dummy.h
> > > +++ b/xen/include/xsm/dummy.h
> > > @@ -95,7 +95,11 @@ static always_inline int xsm_default_action(
> > >               return 0;
> > >           fallthrough;
> > >       case XSM_PRIV:
> > > -        if ( is_control_domain(src) )
> > > +    case XSM_HW_PRIV:
> > > +        if ( is_control_domain(src) && action != XSM_HW_PRIV )
> > > +            return 0;
> > > +        if ( is_hardware_domain(src) &&
> > > +             (action == XSM_HW_PRIV || action == XSM_DM_PRIV) )
> > >               return 0;
> > >           return -EPERM;
> > 
> > Hmm. Isn't DM_PRIV a property applying to the control domain (besides
> > any stub domains), but not the hardware one?
> 
> I ran QEMU in hardware domain to provide devices to a domU.  I thought QEMU
> would better run in hardware domain than control domain.

Leaving stubdoms aside, QEMU has to run in the hardware domain because
the hardware domain is less privileged. QEMU can be attacked or affected
by the guest so it is undesirable to run QEMU in the control domain
which is highly privileged, and considered highly secure / safe.