Re: [PATCH 4/4] xsm/dummy: Allow hwdom SYSCTL_readconsole/physinfo

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Fri, 20 Jun 2025, Jan Beulich wrote:
> On 19.06.2025 02:36, Stefano Stabellini wrote:
> > On Tue, 17 Jun 2025, Jan Beulich wrote:
> >> On 17.06.2025 02:10, Stefano Stabellini wrote:
> >>> On Mon, 16 Jun 2025, Jan Beulich wrote:
> >>>> On 14.06.2025 00:51, Stefano Stabellini wrote:
> >>>>> On Wed, 11 Jun 2025, Jason Andryuk wrote:
> >>>>>> On 2025-06-11 09:27, Jan Beulich wrote:
> >>>>>>> On 11.06.2025 00:57, Jason Andryuk wrote:
> >>>>>>>> Allow the hwdom to access the console, and to access physical
> >>>>>>>> information about the system.
> >>>>>>>>
> >>>>>>>> xenconsoled can read Xen's dmesg.  If it's in hwdom, then that
> >>>>>>>> permission would be required.
> >>>>>>>
> >>>>>>> Why would xenconsoled run in the hardware domain? It's purely a 
> >>>>>>> software
> >>>>>>> construct, isn't it? As a daemon, putting it in the control domain may
> >>>>>>> make sense. Otherwise it probably ought to go in a service domain.
> >>>>>>
> >>>>>> My approach has been to transform dom0 into the hardware domain and 
> >>>>>> add a new
> >>>>>> control domain.  xenconsoled was left running in the hardware domain.
> >>>>>
> >>>>> I think we should keep xenconsoled in the hardware domain because the
> >>>>> control domain should be just optional. (However, one could say that 
> >>>>> with
> >>>>> Denis' recent changes xenconsoled is also optional because one can use
> >>>>> console hypercalls or emulators (PL011, NS16550) for all DomUs.)
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I suppose it could move.  Maybe that would be fine?  I haven't tried. 
> >>>>>> The
> >>>>>> Hyperlaunch code populates the console grants to point at the hardware 
> >>>>>> domain,
> >>>>>> and I just followed that.
> >>>>>>
> >>>>>> One aspect of why I left most things running in the Hardware domain 
> >>>>>> was to not
> >>>>>> run things in the Control domain.  If Control is the highest privileged
> >>>>>> entity, we'd rather run software in lower privileged places. Especially
> >>>>>> something like xenconsoled which is receiving data from the domUs.
> >>>>>
> >>>>> Yes, I agree with Jason. It is a bad idea to run xenconsoled in the
> >>>>> Control Domain because the Control Domain is meant to be safe from
> >>>>> interference. We want to keep the number of potential vehicles for
> >>>>> interference down to a minimum and shared memory between Control Domain
> >>>>> and DomUs is certainly a vehicle for interference.
> >>>>
> >>>> As much as it is when xenconsoled runs in the hardware domain? Especially
> >>>> if the hardware domain is also running e.g. PV backends or qemu 
> >>>> instances?
> >>>
> >>> It looks like you are thinking of the possible
> >>> interference from the Hardware Domain to the Control Domain via
> >>> xenconsoled, correct?
> >>
> >> More like interference with the system as a whole, which simply includes
> >> Control.
> >>
> >>> If that is the case, good thinking. I can see that you have really
> >>> understood the essence of the problem we are trying to solve.
> >>>
> >>> That is not an issue because the Control Domain shouldn't use PV
> >>> console. Instead, it should use the console hypercall, or the
> >>> PL011/NS16550 emulators in Xen.
> >>
> >> Well. I think the underlying concept of Control Domain being highly
> >> privileged needs more general discussion. As indicated elsewhere, I
> >> didn't think disaggregation (whichever way done) would leave any
> >> domain with effectively full privilege. I wonder what others think.
> > 
> > Keep in mind that the threat model here is different from the
> > datacenter. 
> > 
> > But the Control Domain is optional. If the user doesn't want it, the
> > user can avoid it.
> > 
> > Even on a fully static system (no VM creation), it is convenient to have
> > a domain that can monitor the others and trigger domain reset (we are
> > reimplementing domain reboot to be more like a soft reset so that the VM
> > doesn't need to be destroyed and recreated).
> 
> Suggesting that in such an environment Control should have no permission
> to create domains. This would avoid various threats, including e.g.
> massive amounts of dynamic memory allocation.

+1


> > As an example, the Control
> > Domain could be used to monitor a non-safe domain such as Android,
> > detect an Android crash, and trigger an Android reboot.
> 
> Yet at the same time it would have to be prevented from interfering with
> any of the critical domains.
> 
> Altogether this doesn't sound like "highest privilege" to me then.

You are right. We should be more precise with our wording.