This whole issue can be easily solved by adding an int to task_struct, a
system call to set that int, and a slightly modified version of Rik's
patch.
The modified OOM killer checks each task_struct for the new field, and
modifies it's behavior accordingly. When you start a `secure' process,
make sure this int is properly set so the kernel won't kill your process
unless init is the only remaining alternative.
In this case, the only time a `secure' process will ever fail is if your
machine is HOPELESSLY overloaded AND no non-secure processes are running.
In this case, the correct course of action is to shoot the sysadmin (or
alternately the author of a buggy secure process) because the failure
originated with a human and not in the OS memory allocation.
The "safe gnumalloc" solution is okay, but wastes memory. The same is true
of stack preallocation. I think it's better to keep overcommit and have
some user-level control over what we kill.
This is simple, reliable, and efficient. Policy is completely in
user-space. It is also secure -- the 'secure' task(s) never fail unless
the alternative is to hang the machine. And if you wish, you can easily
deadlock or hang the machine instead of killing secure tasks; if the
int=MAXINT then never kill the task no matter what. Make your audit
daemon, init, and whatever else unkillable.
You can also implement memory quotas completely independent of this
scheme. The quotas can be a per-user memory limit, and/or a per-user
guarantee (i.e. 'user dwhysong can always use at least 20 megabytes, but
never more than 100 megabytes').
The only problem I am aware of is that non-secure tasks can be killed.
But, this really isn't so bad, because:
1. it only happens in extreme emergency cases, and
2. they aren't secure tasks anyway, and
3. something has to die or the system goes down.
I think this is the *best possible* solution, because it does whatever is
necessary to keep `secure' tasks running.
Dave
David Whysong dwhysong@physics.ucsb.edu
Astrophysics graduate student University of California, Santa Barbara
My public PGP keys are on my web page - http://www.physics.ucsb.edu/~dwhysong
DSS PGP Key 0x903F5BD6 : FE78 91FE 4508 106F 7C88 1706 B792 6995 903F 5BD6
D-H PGP key 0x5DAB0F91 : BC33 0F36 FCCD E72C 441F 663A 72ED 7FB7 5DAB 0F91
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:28 EST