Request: Enable sysrq by default

For some time now I've been manually adding sysrq_always_enabled=1 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub whenever I install Manjaro. I find it very useful to have access to these shortcuts in the event something causes the system to freeze and I can't switch to a different TTY.

For example, if specific applications lock up the interface and you can't use the keyboard to switch TTY, you can use AltSysRqr to get control of the keyboard back, and then access a different TTY to kill hung processes. Additionally,
while not ideal, I much prefer a kernel sync + reboot (AltSysRqs followed by AltSysRqb) to yanking the power.

When you search for "reboot frozen linux" this is the first thing that comes up:

I think it would be ideal for these options to be available by default, instead of having to force power-off the computer and remembering to enable these manually before a(nother) freeze happens.

Obviously, ideally freezing wouldn't be an issue, but sometimes there's hardware/driver/software issues that are just not avoidable, and a small thing like this is a god-send in the event you run into it.

Thoughts?

3 Likes

For genereal usage it is possible to permanently enable these by doing
echo "1" > /proc/sys/kernel/sysrq

There may be other options required if the ability is needed before the system has fully booted.

See: https://wiki.archlinux.org/index.php/Keyboard_shortcuts

2 Likes

I'm pretty sure it's not enabled by default because it is a potential security issue.
In kernel config:

CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=<bitmask-in-hex>

Note that your command line option overrides /proc/sys/kernel/sysrq (and kernel.sysrq setting in /etc/sysctl.d if it exists)

Kernel documentation: https://www.kernel.org/doc/html/v4.19/admin-guide/sysrq.html

2 Likes

I don't know what other consequences this may have, but I like the idea. Will change my grub settings right away.
In other words here's my upvote :grinning:

While I want sysrq to be enabled by default too, it's frankly a bit risky.
Anyone can then walk up to your computer and make it e.g. reboot with a simple keypress.
I actually find it more "dangerous" than the newly restricted dmesg access.

I prefer to have sysrq enabled as soon as possible, since I don't know when a freeze might occur. Understandable (and acceptable) if the general preference is having it enabled later, though I have yet to see a substantial risk from having it configured the way I have it.

Not sure how having it enabled is more risky than the current Manjaro config. Anyone can currently walk up to a Manjaro computer and if it's at the login screen or logged in, they can shutdown or restart it. Plus, the ability to restart a computer doesn't really give the person access to anything on it; they'd still have to login to get access to anything.

The dmesg access restriction makes more sense since it was access to system log data, which could potentially assist in an attack (specifically: use an as yet unknown vulnerability to gain elevated permissions, since they'd already have basic user rights on the computer, as well as physical access). I'm not sure any of the sysrq commands give access to that kind of information.

Unlike pushing the power button? Removing the cord? If someone has physical access to your machine then you can't stop them from those things. SysRq security matters as server hardening from physical tampering. For desktop it's meaningless.

Okay the reboot was indeed a very bad example :slight_smile:
But you can also use sysrq to dump CPU registers, backtraces, memory info etc.

Of course you're right, anyone with physical access to a computer can do anything.

I'm not opposed to enabling it by default btw.

Well, it is enabled on my system, but only the sync command is allowed. It seems like a reasonable setting and that's probably default for manjaro because I never messed with it.

Fortunately this isn't all or nothing. For example setting kernel.sysrq to 176 (128+32+16) will allow only for syncing,mounting read-only and rebooting.