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.
