1

I'm using Solus 4.0 (in a VM) and trying to make screenshots of "typical" kernel panic output ("BSOD"). The init system in Solus is systemd.

I tried the following commands in the terminal without success:

$ kill -6 1

Doesn't do anything (no echo).

$ sudo kill -SEGV 1

Also does nothing...

# echo c > /proc/sysrq-trigger

Freezes the system but it's not what I need.

Any ideas?

I'd like to see the stack calls and all. It's not about freezing the system with a fork bomb.

References used:

Frederik
  • 11
  • A BSOD is Windows; it's a Blue Screen Of Death. In UNIX/Linux, it is called an Oops. Have looked at https://opensourceforu.com/2011/01/understanding-a-kernel-oops/ ? – Ljm Dullaart Apr 16 '19 at 16:10
  • Yes, that's why I put quotation marks around it. Do you have any idea how to answer my question, though? – Frederik Apr 16 '19 at 16:26
  • The link I added suggests that you could use a kernel module to generate the oops. Rather than copying someone else's work, I referred to it. – Ljm Dullaart Apr 16 '19 at 16:30
  • Thank you. I had considered writing a little C program but I'd like to do it via the terminal. If all else fails, I'll try your suggestion. – Frederik Apr 17 '19 at 07:53

3 Answers3

0

If you would like to see stack traces of the threads running on all CPUs you can

# echo l > /proc/sysrq-trigger

According to, e.g., Wikipedia this

Shows a stack backtrace for all active CPUs.

Erki der Loony
  • 176
  • Thanks, I tried lots of command keys ("c", "l", "p", etc.) but I get

    bash: /proc/sysrq-trigger: Permission denied

    The "magic SysRq key" doesn't work either. Maybe I have to head to the Solus Linux forums?

     – Frederik Apr 17 '19 at 07:55
  • Permission denied probably means that you did not run above commands as root. Try again as root (which I meant to indicate by the "#" prompt) and it should work. However in any case it is possible that the kernel was compiled without support for magic sysrq. But OTOH I think you should not get permission denied but rather /proc/sysrq- trigger should not exist at all. – Erki der Loony Apr 18 '19 at 17:37
  • I ran all commands as root. Nothing happens. – Frederik Apr 23 '19 at 06:58
  • It is possible to selectively disable some of the magic SysRq functionality at kernel compile time, using the CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE configuration parameter, or at runtime, by setting kernel.sysrq to a value that is neither 0 nor 1 in /etc/sysctl.conf, or by just echoing that value to /proc/sys/kernel/sysrq. The kernel admin guide has more info. If the stack-trace command key has been disabled, but other functions remain enabled, that might explain the "permission denied" error. – telcoM Aug 14 '20 at 12:18
0

A reliable way to cause a kernel panic from userspace is to get PID 1 to exit. It's protected from signals, so you'll have to use a different approach, like a debugger: sudo gdb -ex 'call _exit(0)' --pid=1 --batch

Joseph Sible-Reinstate Monica
  • 3,323
-1

Ideally this should not be possible at all, otherwise hackers would be able to bring systems down too easy. If you've found a way to do that, that may be severe security issue.

ivan.ukr
  • 171
  • 1
    How's this any easier than poweroff? Or is that a security issue that we should get rid of too? – Joseph Sible-Reinstate Monica May 30 '20 at 20:57
  • To have tools like poweroff/shutdown/reboot work, user must have certain capability, CAP_SYS_BOOT. That means you can configure user so that it doesn't have it and as result he cannot reboot or shutdown server suddenly. – ivan.ukr May 31 '20 at 08:31
  • So why should forcing a panic "not be possible at all" if it's fine for poweroff to be possible for users with CAP_SYS_BOOT? – Joseph Sible-Reinstate Monica May 31 '20 at 15:23
  • Because poweroff is sort of useful and normal action. While "force kernel panic" is sort of thing that may be useful maybe for kernel developers only. So such things should not be normally part of mainstream OS kernel. Instead, developer has to add to kernel something special that would force kernel panic, if that is really what he needs. This could be for example, custom driver for character device, which, if written special symbol sequence, causes kernel panic. – ivan.ukr Jun 03 '20 at 06:48
  • They both have the same net effect of rendering the system unusable until someone manually reboots it. Why is there a security difference between doing so conventionally and unconventionally? – Joseph Sible-Reinstate Monica Jun 03 '20 at 13:26
  • Still "poweroff" looks like "legitimate" and even "must have" way to bring system down, while kernel panic doesn't look like this and clearly sounds like optional feature. – ivan.ukr Jun 04 '20 at 12:53
  • So you think we should make security decisions based on what things "look" and "sound" like, instead of based on their actual consequences? – Joseph Sible-Reinstate Monica Jun 04 '20 at 13:46
  • Once again. Poweroff is wanted and necessary thing. Kernel panic is unwated and generally unnecesary thing. I think these points are enough reasoning to make decision. And because there is actually no well-known and intentionally documented way to force kernel panic, I think such reasoning worked for kernel developers. – ivan.ukr Jun 04 '20 at 15:03
  • You're wrong about that; there is such a way. See my answer. – Joseph Sible-Reinstate Monica Jun 04 '20 at 15:11
  • I think I am right that at least kernel panic is unwanted and generally unnecessary thing. And at least there is no standard utility similar to poweroff or shutdown to do that in the some standard well-documented way. – ivan.ukr Jun 04 '20 at 17:11
  • A normal power-off is a controlled process that allows server processes to be shut down, filesystems unmounted and write caches cleared, all in an orderly fashion without losing data. A kernel panic abruptly stops all user-space processing (equivalent to kill -9 for everything), and may also prevent an orderly shutdown of filesystems, risking filesystem corruption and data loss as cached writes won't get all the way to the disk. – telcoM Aug 14 '20 at 12:46