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. Jan
