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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan