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

["Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>]

On 2/24/26 02:09, Jan Beulich wrote:
> 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?
What I am saying is it needs to be controlled via XSM, so a means to 
enable that needs to be determined.
V/r,
dps