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

[Jan Beulich <jbeulich@xxxxxxxx>]

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