[bug #59195] Running grub-emu as root under Linux borks the machine requiring a reboot

[Dennis Filder]

URL:
  <https://savannah.gnu.org/bugs/?59195>

                 Summary: Running grub-emu as root under Linux borks the
machine requiring a reboot
                 Project: GNU GRUB
            Submitted by: dfilder
            Submitted on: Sun 27 Sep 2020 04:38:08 PM UTC
                Category: None
                Severity: Major
                Priority: 5 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 
                 Release: 2.02
         Discussion Lock: Any
         Reproducibility: Every Time
         Planned Release: None

    _______________________________________________________

Details:

Debian-BTS: #965026
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=965026>
Architecture: x86_64-linux-gnu
Kernel: Debian 4.19.146-1 (2020-09-17)
Version: 2.02+dfsg1-20+deb10u2, but the latest git revision
(2df291226638261d50fadcab1f5edb6c12ab6cfd, 2020-07-31) shows exactly the same
behaviour (Configured with ./configure --enable-grub-emu-sdl=yes --with-SDL
--with-platform=emu and compiled against SDL 1.2.15+dfsg2-4).

== Description ==

A blind user reported that running grub-emu made his braille and speech
facilities stop and forced him to reboot.  I tried looking into this, and
every time I ran grub-emu as root (which I suspect he did, too) I had to
reboot my machine to make it usable again.  Running it under an unprivileged
user works fine, but only because the SDL backend is using the X server or (if
DISPLAY is unset) reusing the attached terminal (under X the menu is rendered
in the xterm, on console it is rendered onto the virtual console, i.e. copying
characters with GPM still works).

== Reproducer ==

As root:


grub-menu


== Diagnostics ==

For testing I added this menu stanza at the very beginning (with a 5 second
timeout):


menuentry "halt" {
    halt
}


When running unprivileged and not pressing any keys, grub-emu always exitted
gracefully and left the computer in a usable state regardless of how it was
run.  When run as root, even with this stanza in place and not pressing any
keys, the computer would always be rendered unusable until rebooted (with
Ctrl+Alt+Del), even though grub-emu exitted with 0 status code.  Neither of
the following recovery attempts worked:

* Alt-SysRq-K
* Alt-SysRq-R
* timed restart of the X server (hoping it would unbork the graphics setup)
* fbset with a known-to-work setting

The only diagnostically useful info I could come up with is this strace output
of ioctls taken with the "halt" stanza in place:
 

13049 execve("grub-core/grub-emu", ["grub-core/grub-emu"], 0x7ffebe520b78 /*
33 vars */) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon -echo
...}) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
13049 ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=170, ws_xpixel=0, ws_ypixel=0})
= 0
13049 ioctl(3, TUNSETIFF, 0x7fff38f678a0) = 0
13049 ioctl(6, FBIOGET_FSCREENINFO, 0x7fff38f673c0) = 0
13049 ioctl(6, FBIOGET_VSCREENINFO, 0x7fff38f67410) = 0
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67410) = 0
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67410) = -1 EINVAL (Invalid
argument)
13049 ioctl(7, VT_OPENQRY, 0x199e9f0)   = 0
13049 ioctl(8, TIOCNOTTY)               = 0
13049 ioctl(7, KDGKBMODE, 0x7fff38f67344) = 0
13049 ioctl(7, KDGKBENT, 0x7fff38f67344) = 0
13049 ioctl(7, VT_GETSTATE, 0x7fff38f672da) = 0
13049 ioctl(7, VT_ACTIVATE, 0x7)        = 0
13049 ioctl(7, VT_WAITACTIVE, 0x7)      = 0
13049 ioctl(7, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(7, KDGKBMODE, 0x199e9fc)    = 0
13049 ioctl(7, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 ioctl(7, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost -isig -icanon
-echo ...}) = 0
13049 ioctl(7, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
13049 ioctl(7, KDSKBMODE, 0x2)          = 0
13049 ioctl(7, KDSETMODE, 0x1)          = 0
13049 ioctl(7, VT_LOCKSWITCH, 0x1)      = 0
13049 ioctl(6, FBIOGET_VSCREENINFO, 0x7fff38f67350) = 0
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67350) = -1 EINVAL (Invalid
argument)
13049 ioctl(6, FBIOPUT_VSCREENINFO, 0x7fff38f67350) = 0
13049 ioctl(6, FBIOGET_FSCREENINFO, 0x7fff38f673f0) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig -icanon -echo ...}) = 0
13049 ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo
...}) = 0
13049 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
13049 exit_group(0)                     = ?
13049 +++ exited with 0 +++


The only thing dubious I can spot here is the VT_LOCKSWITCH call which is
missing its corresponding VT_UNLOCKSWITCH call.  I don't know if this happens
in SDL or GRUB code.  Grepping for it in the GRUB codebase yielded nothing.

Let me know if I can add anything more.




    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59195>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/