bugGNU GRUB - Bugs: bug #59195, Running grub-emu as root under...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

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

Submitter:  Dennis Filder <dfilder>
Submitted:  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: 
Open/Closed:  Open Release:  2.02
Release:  Reproducibility:  Every Time
Planned Release:  None

Sun 27 Sep 2020 04:38:08 PM UTC, original submission:  

Debian-BTS: #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.

Dennis Filder <dfilder>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dfilder (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code