0

If one were to pursue the crazy and dangerous idea of writing a kernel module in Linux that...

  • Finds a process specified by PID in the kernel's internal process table
  • Extracts the begin/end adresses of the process in memory from the table
  • Overwrites all memory of this process with 0's

then ...

  • Would this be a way to instantaneously terminate any process?
  • How "unsafe" would this be? Would it be possible at all without insantly causing a kernel panic?
Vimo
  • 9
  • 1
  • You'd completely corrupt the process (destroy its heap/stack/other segments), but as you wouldn't have affected the process table (or the task_struct, etc.), then the kernel wouldn't consider it "terminated". – Oliver Charlesworth Mar 10 '13 at 13:55
  • This will cause a SIGILL on next running of the process (most probably). And the easier way is just to send signal. – osgx Mar 10 '13 at 13:55
  • That said, why are you asking this question? Is this "an actual problem that you face"? If you want to terminate a process, why not just send `SIGKILL`? – Oliver Charlesworth Mar 10 '13 at 13:55
  • I'm just wondering, because there are kinds of processes where termination can't be guaranteed even when sending the appropriate signal with the appropriate access rights. I'm looking for a way which ensures a 100% success rate without any questions asked to kill a process. – Vimo Mar 10 '13 at 13:58
  • 3
    @Vimo: Can you give an example of where `SIGKILL` doesn't work? Also, if that's your actual problem, then you should probably frame your question around the **problem**, not around a possible **solution**. (See [*What is the XY problem?*](http://meta.stackexchange.com/a/66378/181277)) – Oliver Charlesworth Mar 10 '13 at 13:59
  • 1
    SIGKILL doesn't work if the process is hanging inside a system call (http://stackoverflow.com/questions/8600430/cases-in-which-sigkill-will-not-work). But in that case, your "solution" won't work either. – Thomas Mar 10 '13 at 14:43

1 Answers1

1

Overwriting the process's code with zero (in x86) is most likely NOT going to stop the process from executing, but since that becomes a plain instruction, I think ADD EAX, [EAX], it will just walk all the way to the end of the code segment [unless EAX is pointing at invalid memory]. Obviously, if the registers for the process are set to some invalid memory address [in 64-bit, a value that is non-canonical will be good, in 32-bit, something that is write-protected, such as zero], and/or the memory is filled with something that causes an "invalid opcode", then that would be a different matter.

I really don't see how this can be "better" than using SIGKILL (aka KILL -9 pid) - if the process is blocked inside the kernel and somehow not leaving the kernel, it won't help to overwrite the code-space, since the process isn't running that code anyway. If there is a bug in the kernel, it's not really going to matter what you do to the process' userspace memory. Fix the kernel bug!

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227