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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Tue, 18 Mar 2025, Jan Beulich wrote:
> On 18.03.2025 00:55, Stefano Stabellini wrote:
> > 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.
> 
> Yet having access to the hardware, hwdom can likely also do about anything
> to the system. IOW I'd consider this "highly privileged" too, just not from
> a pure software perspective. If you want a secure / safe environment, I
> fear you won't get around using further (stub?) domain(s) to run qemu in.

Traditionally, from an upstream Xen Project perspective, it is important
to support as many hardware platforms as possible. The goal is to
provide the best possible out-of-the-box experience, including support
for devices like the Raspberry Pi 4 (RPi4), which has certain quirks and
limited IOMMU support.  

However, when considering safety (similar concepts also apply to
security) it is necessary to write down assumptions. One key assumption
is that the system includes an IOMMU and that all DMA-capable devices
are protected by it.  

There are boards, such as the RPi4, that do not meet these assumptions.
While Xen can and should run on such hardware, the level of flexibility
in configuring safe environments on these boards will be limited.  

For example, on the RPi4, I would not recommend to run QEMU in an unsafe
hardware domaini because the hardware domain will end up having control
over unprotected DMA-capable devices that can be used to harm the
system. However, it will be possible to run QEMU in an unsafe hardware
domains on platforms were all DMA-capable devices that can harm the
system are IOMMU protected, such as Xilinx MPSoC when configured
correctly.