Is there any way I can crash a kernel on purpose (e.g., kernel panic, blue screen, black screen, or whatever). Assume I can change any registers and have administrative privilege of the system. I would like to demonstrate this on both Windows and Linux platforms.
Thanks for any inputs!
In Linux, you must compile the kernel with the CONFIG_MAGIC_SYSRQ option, then you can crash the kernel by writing the crash command into /proc/sysrq-trigger, or by pressing Alt+SysRq+C.
See the documentation for details.
In Windows, you must set the CrashOnCtrlScroll registry key for the keyboard driver, and reboot, then you can press Ctrl+Scroll Lock to crash the kernel.
See the documentation for details.
echo c > proc/sysrq-trigger
There are several ways to do this:
Write your own kernel module and load it, make sure you call BUG() or BUG_ON().
Use sysrq; echo c > /proc/sysrq-trigger, with this make sure to install kdump if you are interested in capturing a vmcore file.
Related
We are running Yocto Linux for an embedded application. I'm looking for a way to programatically control the Caps Lock state either through bash prompt or code, either set the state or read the state so that the state is known, without using X-Windows. We do not have X-Windows libraries installed and we cannot add them at this time. All the solutions that we've found searching require an X-Windows library or use of an X tool, such as xmodmap. Any help would be greatly appreciated. This seems like such a simple thing to require bringing in X-Windows into our embedded device for. Isn't there a sysfs entry we can just read?
This question is similar to How can I turn on/off Caps Lock, Scroll Lock, Num Lock key programatically on Linux, but I'm looking for a solution without requiring X-Window Libraries or utilities.
A little bit of background. The caps lock state is not maintained by the keyboard itself, but by whichever piece of software is managing the keyboard. The keyboard simply sends the software a code every time the caps lock key is pressed, the software determines whether that is turning caps lock on or off, sets a flag accordingly, and sends a command back to the keyboard to turn the caps lock LED on or off.
So in this case, if you're not using X, I assume the software managing the keyboard is the Linux kernel's console. This has a number of ioctls which can be used to manage the caps lock flag, and separately the LED state. See the man page console_ioctl(4) for more details.
There is also a setleds(1) program (man page) which can be used to easily issue these ioctls. Its part of the kbd package of tools which appears to already have a Yocto recipe.
I'm on OSX, using canopy. Does anybody know what the shortcut for interrupting the kernel is? Thanks.
There is no shortcut for interrupting the kernel. That command, along with restarting the kernel, is in the Run menu, which also shows the shortcut for the restart kernel command. Note that because of the nature of the interaction between Python and C extensions, neither command is guaranteed to work, though restart is more likely to in a pinch.
This question deals with why you can't read the GDTR and LDTR in user-mode GDB. But I don't see why it shouldn't be possible when debugging a Linux kernel (with KGDB compiled in), using GDB on another machine with serial cable.
The kernel being debugged should be able to tell the debugger the values of the GDTR and LDTR, but it doesn't seem there is any GDB command to make it do so. Is there a good reason for this? Is it just something which nobody has implemented?
As you say, nobody implemented it.
gdb in particular doesn't consider those valid registers, so the kernel debug interface doesn't even try to send them.
Unless you are willing to change gdb, you must use a workaround to get that information. One such possibility I can think of is the ThreadExtraInfo command which should be able to send arbitrary string message that gets printed in gdb. So you could add that information in kernel/debug/gdbstub.c.
I am trying to remotely debug a linux kernel running on an arm cortex-a9 target using jtag probe and gdb.
I can connect to the kernel and halt it with gdb. I am able to set breakpoints in the kernel code and gdb confirms there placement as well but the problem is that once I start the execution and issue a continue command, the breakpoints are never hit and the kernel continues to run....
Please help me out in this regard.
Thanks.
As pointed in this thread, you should set the breakpoints as hardware breakpoints, namely - using the hbreak command. Only then the breakpoints will be hit.
For anyone reading this, the debugger will not break with software breakpoints by default, see the relevant doc:
"If the architecture that you are using supports the kernel option CONFIG_STRICT_KERNEL_RWX, you should consider turning it off. This option will prevent the use of software breakpoints because it marks certain regions of the kernel’s memory space as read-only. If kgdb supports it for the architecture you are using, you can use hardware breakpoints if you desire to run with the CONFIG_STRICT_KERNEL_RWX option turned on, else you need to turn off this option."
at https://www.kernel.org/doc/html/v4.14/dev-tools/kgdb.html
Disable RWX and recompile, then software breakpoints should work (they started working normally here after this)
Is some cases, KASLR (Kernel Address Space Layout Randomization) can be the culprit.
Even though you setup hbreak, the actual code location can be different from the address seen from the .elf file when using KASLR, so either pass --append "nokaslr" to the kernel boot argument, or configure the kernel with RANDOMIZE_BASE=n. This applies for arm64 and x86_64. (maybe other architectures too).
I was debugging a program in which I hit
int 0x80
I know this means a system call and then the kernel executed it. However, GDB does not allow me to look at the instructions run by the kernel while executing this system call. It just executes the system call and takes me to the next instruction.
Is there anyway I can look into the kernel mode code while debugging a user mode program? If not, then what are the over best alternatives available to me?
Is there anyway I can look into the kernel mode code while debugging a user mode program?
No.
(Actually, you could do that if you use UML, but that is likely too complicated for you to set up.)