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
