On 29.01.2026 03:42, Stefano Stabellini wrote: > On Wed, 28 Jan 2026, Jan Beulich wrote: >> On 23.01.2026 02:06, Stefano Stabellini wrote: >>> @@ -742,17 +758,36 @@ static long >>> guest_console_write(XEN_GUEST_HANDLE_PARAM(char) buffer, >>> if ( copy_from_guest(kbuf, buffer, kcount) ) >>> return -EFAULT; >>> >>> - if ( is_hardware_domain(cd) ) >>> + /* >>> + * Take both cons->lock and console_lock: >>> + * - cons->lock protects cons->buf and cons->idx >>> + * - console_lock protects console_send and is_focus_domain >>> + * checks >>> + * >>> + * The order must be respected. guest_printk takes the >>> + * console_lock so it is important that cons->lock is taken >>> + * first. >>> + */ >>> + spin_lock(&cons->lock); >>> + nrspin_lock_irq(&console_lock); >>> + if ( is_focus_domain(cd) ) >> >> Why would any of the domains possibly being permitted to be "focus" suddenly >> gain direct access here? Full access in do_console_io() is still prevented by >> the XSM check there, afaict. Cc-ing Daniel, as it's not quite clear to me >> whether to introduce another XSM check here, whether to check ->is_console >> directly, or yet something else. > > The XSM check still happens first in do_console_io() via > xsm_console_io(XSM_OTHER, current->domain, cmd), which validates that > the domain has permission to use console_io hypercalls. The focus check > is an additional restriction that only allows reading when the domain > has focus: it doesn't grant new permissions. Dom0less domains with > input_allowed = true are already permitted by XSM policy to use > console_io;
Are they? I don't see any XSM or Flask code checking that flag. What the dummy xsm_console_io() checks is ->is_console. However, what indeed I didn't pay attention to when writing the original comment is that guest_console_write() has only a single caller, do_console_io(). So there's no concern in this regard here as long as no new caller appears. Jan
