Re: [PATCH] xsm: move the console read properly under xsm

[Jan Beulich <jbeulich@xxxxxxxx>]

On 23.02.2026 19:49, Daniel P. Smith wrote:
> On 2/23/26 10:22, Jan Beulich wrote:
>> On 19.02.2026 19:45, Daniel P. Smith wrote:
>>> --- a/xen/drivers/char/console.c
>>> +++ b/xen/drivers/char/console.c
>>> @@ -554,7 +554,7 @@ struct domain *console_get_domain(void)
>>>       if ( !d )
>>>           return NULL;
>>>   
>>> -    if ( d->console->input_allowed )
>>> +    if ( !xsm_console_io(XSM_OTHER, d, CONSOLEIO_read) )
>>>           return d;
>>>   
>>>       rcu_unlock_domain(d);
>>> @@ -595,7 +595,7 @@ static void console_switch_input(void)
>>>           d = rcu_lock_domain_by_id(domid);
>>>           if ( d )
>>>           {
>>> -            if ( !d->console->input_allowed )
>>> +            if ( xsm_console_io(XSM_OTHER, d, CONSOLEIO_read) )
>>>               {
>>>                   rcu_unlock_domain(d);
>>>                   continue;
>>
>> At least the latter of these two can be called from an IRQ handler, and can
>> be called with IRQs off. Flask's avc_audit() looks to be using a spinlock,
>> which isn't IRQ-safe. (There may be other lock involved; I merely went as far
>> as I needed to to find the first one.) IOW I fear you can't call
>> xsm_console_io() from here.
> 
> Apologies that I didn't consider the IRQ context. With that said, we 
> can't be wiring non-XSM access control paths that circumvent FLASK's 
> ability to control domain access to a resource.

I feel like I can interpret this last sentence in different ways. Are you
suggesting that this effort needs to be dropped, and the situation needs
leaving as is? If so, aren't there options to move at least a little
closer to what is wanted?

Jan