10

Is there any way to make a program that cannot be interrupted (an uninterrupted program)? By that, I mean a process that can't be terminated by any signal, kill command, or any other key combinations in any System: Linux, windows etc.

First, I am interested to know whether it's possible or not. And if yes, upto what extend it is possible?

I mostly write code in C, C++, and python; but I don't know any of such command(s) available in these programming languages.

Is it possible with assembly language, & how ? Or in high level language c with embedded assembly code(inline assembly)?

I know some signals are catchable some are not like SIGKILL and SIGSTOP.

I remember, when I was use to work on Windows-XP, some viruses couldn't be terminated even from Task Manager. So I guess some solution is possible in low level languages. maybe by overriding Interrupt Vector Table.

Can we write an uninterrupted program using TSRs(Hooking)? Because TSR can only removed when the computer is rebooted or if the TSR is explicitly removed from memory. Am I correct?

I couldn't find any thing on Google.

Grijesh Chauhan
  • 57,103
  • 20
  • 141
  • 208
  • 13
    I really hope there isn't. –  Sep 15 '12 at 13:18
  • 2
    `kill -KILL` kills every user process without much ado, except if it's in an uninterruptible sleep state. – Daniel Fischer Sep 15 '12 at 13:18
  • 4
    Now the question is **why** would you want such behaviour? – Daniel Fischer Sep 15 '12 at 13:24
  • 1
    On windows, you could opt for Pure Evil (tm) and do all your processing in response to a DLL_PROCESS_DETACH notification. – harold Sep 15 '12 at 22:19
  • @DanielFischer that time I just wanted to know whether it is possible to write an Uninterruptable process, Originally question came to my mind during my thesis work(malware) I remember some code can do this in windows environment. This is the question for which I created an account here on SO. – Grijesh Chauhan Jun 18 '13 at 06:36
  • 1
    @GrijeshChauhan I see. Professional curiosity. I'm glad you created an account, you're a valuable contributor. – Daniel Fischer Jun 18 '13 at 11:51
  • @DanielFischer thanks for your appreciation!, Are you teacher **?** – Grijesh Chauhan Jun 18 '13 at 13:22
  • Not really, but kind-of sort-of part-time, I am sort of a teacher. And of course on [SO] I (try to) teach. – Daniel Fischer Jun 18 '13 at 13:51
  • @DanielFischer Hi! Do you have any idea why [this code](http://codepad.org/Q3RNPv32) runs in C? It must be a bug in compiler or not! – Grijesh Chauhan Jul 24 '13 at 20:21
  • 1
    It's a compiler extension. Well, two. Empty initializer list and zero-length arrays. If you compile to `-std=c99` or `-std=c11` and tell the compiler to be `-pedantic` (or `-pedantic-errors` may be necessary, depends on the compiler), you'll get an error. It's not standard-conforming C indeed. It's not a bug, unless you argue that the compiler enabling extensions by default is a bug (IMO it's just a bad design decision, not a bug). – Daniel Fischer Jul 24 '13 at 20:31
  • @DanielFischer Thanks! Yes it give me an error: `zero or -ve size array` with `-pedantic-errors` to my gcc4.4.7. So its GCC extension! – Grijesh Chauhan Jul 24 '13 at 20:39
  • clang also has them. My gcc-4.7.2 gave an `error: zero or negative size array ‘array’` already with `-pedantic`, clang wanted `-pedantic-errors` to fail the compilation. – Daniel Fischer Jul 24 '13 at 20:42
  • @DanielFischer Thanks for this new information! My gcc 4.4.7 is greedy it need `-error` too. Can you give me a link that says its compiler extension. – Grijesh Chauhan Jul 24 '13 at 20:47

3 Answers3

4

Well, possibly one can write a program which doesn't respond for most signals like SIGQUIT, SIGHUP etc. - each kind of "kill" is actually a kind of signal sent to program by kernel, some signals means for the kernel that program is stuck and should be killed. Actually the only unkillable program is kernel itself, even init ( PID 1 ) can be "killed" with HUP ( which means reload ).

Learn more about signal handling, starting with kill -l ( list signals ) command.

Regarding Windows ( basing on "antivirus" tag ) - which actually applies to linux too - if you just need to run some antivirus user is unable to skip/close, it's permission problem, I mean program started by system, and non-administrative user without permission to kill it, won't be able to close/exit it anyway. I guess lameusers on Windows all over the world would start "solving" any problems they have by trying to close antivirus first, just if it would be possible :)

netcoder
  • 66,435
  • 19
  • 125
  • 142
Piotr Wadas
  • 1,838
  • 1
  • 10
  • 13
  • Actually, when you write a program which ignores most signals, mostly acting as "unkillable", how will you deal with it, when YOU will need to stop it? The way particular program behaves on receiving particular signal is up to you - you can e.g. make program to commit suicide when received "HUP" signal, or to treat any signal as reload/restart itself request.. PS. If you just need your program to restart itself transparently when I die, put it somewhere into inittab or other init configuration – Piotr Wadas Sep 15 '12 at 13:16
  • this way program will be started by init, and will behave like text console - will be restarted each time, no matter for what reason it was stopped or had died. Note, that if program is buggy, this can overload system, by restarting it again and again aggresively. – Piotr Wadas Sep 15 '12 at 13:19
  • @JaggedO'Neill: on Linux you can only send signals to _init_ which he has installed signal handlers for. POSIX says that `kill()` can pretend some process does not exist, and mentions _init_ and the scheduler as possible implementation-defined processes to which signals cannot be sent. – ninjalj Sep 15 '12 at 17:23
  • @JaggedO'Neill: also IIRC, sending SIGKILL to `upstart` is the way to make it reload service files. Whether upstart's `init` captures `KILL` or the kernel restarts it, I don't know. – ninjalj Sep 15 '12 at 17:27
  • @ninjalj : Is an uninterrupted program is possible using TSR? Any Idea? – Grijesh Chauhan Oct 06 '12 at 12:21
  • @netcoder Please revisit my question, I have some more queries! – Grijesh Chauhan Oct 06 '12 at 16:28
4

On Linux, it is possible to avoid being killed by one of two ways:

  1. Become init (PID 1). init ignores all signals that it does not catch, even normally unblockable ones like SIGSTOP and SIGKILL.
  2. Trigger a kernel bug, and get your program stuck in D (uninterruptible wait) state.

For 2., one common way to end up in D state is to attempt to access some hardware that is not responding. Particularly on older versions of Linux, the process would become stuck in kernel mode, and not respond to any signals until the kernel gave up on the hardware (which can take quite some time!). Of course, your program can't do anything else while it's stuck like this, so it's more annoying than useful, and newer versions of Linux are starting to rectify this problem by dividing D state into a killable state (where SIGKILL works) and an unkillable state (where all signals are blocked).

Or, of course, you could simply load your code as a kernel module. Kernel modules can't be 'killed', only unloaded - and only if they allow themselves to be unloaded.

bdonlan
  • 224,562
  • 31
  • 268
  • 324
2

You can catch pretty-much any signal or input and stay alive through it, the main exception being SIGKILL. It is possible to prevent that from killing you, but you'd have to replace init (and reboot to become the new init). PID 0 is special on most Unixes, in that it's the only thing that can't be KILL'd.

Nicholas Wilson
  • 9,435
  • 1
  • 41
  • 80