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?

6 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.

1 Like

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.

1 Like

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.

1 Like

True, that is very useful. I don't see any reason not to enable everything besides the logs/data dumps:
4+16+32+64+128+256 = 500

sysrq codes

2 = 0x2 - enable control of console logging level
4 = 0x4 - enable control of keyboard (SAK, unraw)
8 = 0x8 - enable debugging dumps of processes etc.
16 = 0x10 - enable sync command
32 = 0x20 - enable remount read-only
64 = 0x40 - enable signalling of processes (term, kill, oom-kill)
128 = 0x80 - allow reboot/poweroff
256 = 0x100 - allow nicing of all RT tasks

Are there any other qualms? Or could this be raised to the core Manjaro team?

That is not permanent.

kernel.sysrq=1 should be added to /etc/sysctl.d/99-sysctl.conf to make it permanent.

2 Likes

Or, you can add

sysrq_always_enabled=1

to your GRUB command line.

1 Like

Since no one seems opposed, pinging @philm

Would it be possible to have this enabled by default for the upcoming 18.1.0 release?

I've just skimmed the linked kernel documentation and there are no mentions of security issues, other than

which seems to be a useful security-related feature.

I know Ubuntu disabled sysrq so there must be some reason to not have it enabled by default.

I can't see that preventing something happening when an attacker has physical access as a valid reason, e.g. who keeps a secure server in a location where anyone can walk up to it and dump CPU registers but can't install a hardware keylogger?

From http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/security-sysrq.html,

which seems like there's a larger attack surface than the physical keyboard but how many servers have a serial console enabled and accessible to an external interface?

It looks like Arch have it disabled by default, and Arch normally does things for a good reason, so I may be missing something. From https://wiki.archlinux.org/index.php/Sysctl#Configuration :

2 Likes

Maybe because it does not work on all systems. On some laptops the SysRq key is also a Fn key so it does not work as expected.

It is trivial to enable if the user wants however. So I do not think it really matters.

2 Likes

This might be a very silly question, but I wanted to find out what is the SysRq key for my system. Any way of finding it out?

The key that has SysRq written on it. It is usually the same key as the PrtSc key.

If you do not have that key, you might be able to bind another key, but that is for another person to answer.

Not all keyboards have it labeled. My Thinkpad, for example, has FnS designated as the SysRq key. Sometimes the PrtSc key will work even if it doesn't have SysRq specifically labelled on it.

If it's not specifically labelled on your keyboard, I'd duckduckgo SysRq and the model of your computer to find out if it has something already bound to it.

1 Like

Sadly I am using a LG Gram laptop and I am not able to find the key binding for SysRq. If any one knows it will be very nice. I thought I should also clarify the need of this button. I configured my system without any swap, because I don't want excessive writing on my SSD. The problem I faced is, if some application/program exhausts the RAM, my system freezes and I had to hard reboot it. It happened with me some time now. I decided to keep a zram using systemd-swap package. But just in case if OOM Killer fails to kill such application I dont want to force reboot again. Hence I want to find the key binding.