Linux - KernelThis forum is for all discussion relating to the Linux kernel.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I've been trying, for research/fun purpose, to crash the kernel from specific kernel functions (or to render the system unuseable) after testing a condition in fs/exec.c , lets say inside do_execveat_common().
I've tried almost everything, from a divbyzero, null dereference, infinite loop, ... Kernel displays some error, but is still alive and system runs. I'm beginning to understand that this execve* kernel code is executed after a fork of some sort, so only the executed process will die, not the kernel.
I've tried as well to call various functions (without any knowledge of them) like emergency_sync();
kernel_restart(NULL);
or ctrl_alt_del(),
but it actually doesnt compile.
My question is then, how can I f*ck up the kernel from here?
Many thanks!
Last edited by satanfu; 11-21-2017 at 01:24 AM.
Reason: precisions
Well, I suppose that I could mention that certain Universities actually created a crash system command in their Unix timesharing systems of yesteryear. (It proved to be the best way to persuade bored-but-brilliant young students from finding other ways to crash it: "make the process trivially easy to do, therefore no longer amusing.")
But seriously ... for very obvious reasons, the kernel is designed to protect itself against anything that any user process might (maliciously or accidentally) do.
User-land processes of course cannot call any function within the kernel code. It should come as no surprise to you that user-land code which attempts to do so will not compile.
Last edited by sundialsvcs; 11-20-2017 at 10:58 PM.
Well, I suppose that I could mention that certain Universities actually created a crash system command in their Unix timesharing systems of yesteryear. (It proved to be the best way to persuade bored-but-brilliant young students from finding other ways to crash it: "make the process trivially easy to do, therefore no longer amusing.")
But seriously ... for very obvious reasons, the kernel is designed to protect itself against anything that any user process might (maliciously or accidentally) do.
User-land processes of course cannot call any function within the kernel code. It should come as no surprise to you that user-land code which attempts to do so will not compile.
Hi sundialsvcs, please read me well. The code I'm patching is kernel sources (fs/exec.c). Those kernel functions are called when a userspace program invokes the exec syscall. Its obvious that the kernel should be resistant to a malicious userspace process.
This code is called when a process is exec(), but is kernel code. The purpose of the patch is for example to tell the kernel to crash if user exec() a process at 23:42.
Maybe: look at the kernel code that handles=performs SysRq c
Or maybe (my wild-guess) call panic() in your modified kernel code. Idk, sorry.
p.s. 'Welcome to LQ'.
Hi sundialsvcs, please read me well. The code I'm patching is kernel sources (fs/exec.c). Those kernel functions are called when a userspace program invokes the exec syscall. Its obvious that the kernel should be resistant to a malicious userspace process.
This code is called when a process is exec(), but is kernel code. The purpose of the patch is for example to tell the kernel to crash if user exec() a process at 23:42.
Seems to me that it ought to kill the requestingprocess, not burn-down the entire forest.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.