Re: [PATCH 3/4] xen: Add DOMAIN_CAPS_DEVICE_MODEL & XEN_DOMCTL_CDF_device_model

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 16 Jun 2025, Jan Beulich wrote:
> On 14.06.2025 00:47, Stefano Stabellini wrote:
> > On Wed, 11 Jun 2025, Jan Beulich wrote:
> >> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>> To add more flexibility in system configuration add the new
> >>> DOMAIN_CAPS_DEVICE_MODEL flag and XEN_DOMCTL_CDF_device_model.
> >>>
> >>> Thie new flag corresponds to allowing XSM_DM_PRIV for the domain.  This
> >>> will enable running device model emulators (QEMU) from the assigne
> >>> domain for multiple target domains.
> >>>
> >>> Stubdoms assign target allowing the stubdom to serve as the device
> >>> model for a single domain.  This new flag allows the single domain to
> >>> provide emulators for multiple guests.
> >>>
> >>> The specific scenario is a disaggregated system with the hardware domain
> >>> providing device models for muitple guest domains.
> >>
> >> Why the hardware domain? Unless a DM also needs access to some of the
> >> physical hardware, it ought to run in a separate domain. Conceivably
> >> such a domain could service multiply guests, so maybe the "single
> >> target" concept presently used for stubdom simply needed extending?
> > 
> > Not necessarily. While it is possible to have driver domains, it is not
> > the default configuration.
> > 
> > In a default configuration, the hardware domain gets all the hardware by
> > default and therefore will also run the PV backends and Virtio backends.
> > The Virtio backends require DM hypercalls. Let me elaborate further.
> > 
> > In the datacenter, we have Dom0 typically with all the hardware, the
> > backends (PV and Virtio), and also the toolstack. Then all other domains
> > are created dynamically by the toolstack. Driver domains are possible
> > but not very common.
> > 
> > In automotive/embedded, the total number of domains is static, so we can
> > create them using dom0less. We don't need the toolstack to create VMs.
> > Also, we have safety concerns, so we want to take away as much
> > privileges as possible from Dom0.
> 
> At least purely by the wording, this ...
> 
> > This is easy because thanks to
> > dom0less, we don't need the toolstack and we don't need to create VMs
> > dynamically.
> > 
> > So the model is that Dom0 becomes the hardware domain: it has all the
> > drivers and backends but it is not privileged in the sense of
> > creating/destroying other VMs. If a user wants to have Dom0 "super
> > powers", they can create an optional Control Domain. The Control Domain
> > is expected to be tiny, such as XTF or Zephyr. It will have the ability
> > that Dom0 used to have but without the drivers. From a privilege
> > perspective, the Control Domain could create additional VMs, but in
> > automotive/embedded it is not expected to be a use-case because the
> > total number of VMs is still static. 
> > 
> > So your point about driver domains. Yes, one can have driver domains the
> > same way that one can have driver domains in the datacenter but it is
> > not the default.
> 
> ... kind of contradicts this: Running e.g. qemu in Dom0 gives Dom0 quite
> a bit of extra privilege.

Yes, in an ideal world that would not be necessary. However, in
automotive Virtio has become the standard. While there are efforts
ongoing to rework the Virtio protocol to have a better security/safety
profile, we need to provide something that works today. Even PV drivers
are not perfect in that regard because I don't think we can claim they
are free from interference but that is another topic.

In order to provide something that works today, we need to have support
for virtio backends in the hardware domain. Like you said, that gives
quite a bit of extra privilege to the hardware domain which is not
acceptable when targeting a "safe" VM such as the Control Domain.

Thus, we have another series to restrict DM and foreign mapping
hypercalls from being able to target "safe" domains. In other words, the
patch series will prevent the hardware domain from being able to target
the Control Domain or another DomU configured as "safe" with DM
hypercalls or foreign mapping hypercalls.

It will be up to the user to decide which domUs the harwdare domain will
be able to target. That way, the user will still be able to configure
one or more VMs are completely protected from interference from the
hardware domain at the cost of having no (traditional) virtio devices.