On Thu, 12 Oct 2000, Matthew Hawkins wrote:
>
> Seriously, am I missing something obvious or is it far simpler just to
> keel over and die if the system goes OOM? I mean, seriously, if the
> administrator lets it get to that state then he/she/it deserves a dead
> system. It's akin to having your car run out of petrol - you don't
> start shooting passengers because their extra load made the engine chew
> more. You pack up your kitty and go to the nearest petrol station and
> buy more, plug it into the car then learn from the experience so this
> fringe case of it happening doesn't happen again. I don't really see
> much difference between a car going "OOP" and a computer going OOM.
> Should we start deleting files according to some randomly-chosen
> heueristic if a filesystem goes "OOS" ?
Excellent point. However, the idea is to kill an attacker if your 'car'
is being hijacked.
Whatever is being designed should ideally have zero impact on the usual
performance and only come into play if something runs away, deliberately
or by accident.
If Linux doesn't track down and kill deliberate attempts to kill the
system, there will always be those who say; "Linux is no good because
a user can readily kill it....". Of course we could track down and
kill those who say this, but it'd get messy.
FYI, a fork() bomb on my Sun Workstation does not kill it. Also
malloc()ing and writing all over the place doesn't kill it either.
Script started on Wed Oct 11 10:41:38 2000
# cat xxx.c
main()
{
for(;;)
fork();
}
# gcc -o xxx xxx.c
# ./xxx
^C
# # ^C
# ps
PID TTY TIME CMD
24800 pts/1 0:00 xxx
24335 pts/1 0:00 sh
24688 pts/1 0:00 xxx
24690 pts/1 0:00 xxx
24692 pts/1 0:00 xxx
24694 pts/1 0:00 xxx
24696 pts/1 0:00 xxx
24697 pts/1 0:00 xxx
24699 pts/1 0:00 xxx
24701 pts/1 0:00 xxx
24703 pts/1 0:00 xxx
24704 pts/1 0:00 xxx
24706 pts/1 0:00 xxx
24708 pts/1 0:00 xxx
24710 pts/1 0:00 xxx
24712 pts/1 0:00 xxx
24714 pts/1 0:00 xxx
24716 pts/1 0:00 xxx
24717 pts/1 0:00 xxx
24719 pts/1 0:00 xxx
24720 pts/1 0:00 xxx
24721 pts/1 0:00 xxx
24722 pts/1 0:00 xxx
24723 pts/1 0:00 xxx
24724 pts/1 0:00 xxx
24725 pts/1 0:00 xxx
24726 pts/1 0:00 xxx
24727 pts/1 0:00 xxx
24728 pts/1 0:00 xxx
24729 pts/1 0:00 xxx
24730 pts/1 0:00 xxx
24731 pts/1 0:00 xxx
24732 pts/1 0:00 xxx
24733 pts/1 0:00 xxx
24734 pts/1 0:00 xxx
24735 pts/1 0:00 xxx
24736 pts/1 0:00 xxx
24737 pts/1 0:00 xxx
24738 pts/1 0:00 xxx
24739 pts/1 0:00 xxx
24740 pts/1 0:00 xxx
24741 pts/1 0:00 xxx
24742 pts/1 0:00 xxx
24743 pts/1 0:00 xxx
24744 pts/1 0:00 xxx
24801 pts/1 0:00 ps
24687 pts/1 0:00 xxx
24689 pts/1 0:00 xxx
24691 pts/1 0:00 xxx
24693 pts/1 0:00 xxx
24695 pts/1 0:00 xxx
24698 pts/1 0:00 xxx
24700 pts/1 0:00 xxx
24702 pts/1 0:00 xxx
24705 pts/1 0:00 xxx
24707 pts/1 0:00 xxx
24709 pts/1 0:00 xxx
24711 pts/1 0:00 xxx
24713 pts/1 0:00 xxx
24715 pts/1 0:00 xxx
24718 pts/1 0:00 xxx
24653 pts/1 0:00 xxx
24610 pts/1 0:00 xxx
24614 pts/1 0:00 xxx
24615 pts/1 0:00 xxx
24616 pts/1 0:00 xxx
24617 pts/1 0:00 xxx
24618 pts/1 0:00 xxx
24619 pts/1 0:00 xxx
24620 pts/1 0:00 xxx
24621 pts/1 0:00 xxx
24622 pts/1 0:00 xxx
24623 pts/1 0:00 xxx
24624 pts/1 0:00 xxx
24625 pts/1 0:00 xxx
24626 pts/1 0:00 xxx
24627 pts/1 0:00 xxx
24628 pts/1 0:00 xxx
24629 pts/1 0:00 xxx
24630 pts/1 0:00 xxx
24631 pts/1 0:00 xxx
24632 pts/1 0:00 xxx
24686 pts/1 0:00 xxx
24685 pts/1 0:00 xxx
24684 pts/1 0:00 xxx
24683 pts/1 0:00 xxx
24682 pts/1 0:00 xxx
24681 pts/1 0:00 xxx
24680 pts/1 0:00 xxx
24679 pts/1 0:00 xxx
24678 pts/1 0:00 xxx
24677 pts/1 0:00 xxx
24676 pts/1 0:00 xxx
24675 pts/1 0:00 xxx
24674 pts/1 0:00 xxx
24673 pts/1 0:00 xxx
24672 pts/1 0:00 xxx
24671 pts/1 0:00 xxx
24670 pts/1 0:00 xxx
24669 pts/1 0:00 xxx
24668 pts/1 0:00 xxx
24667 pts/1 0:00 xxx
24666 pts/1 0:00 xxx
24665 pts/1 0:00 xxx
24664 pts/1 0:00 xxx
24663 pts/1 0:00 xxx
24662 pts/1 0:00 xxx
24661 pts/1 0:00 xxx
24660 pts/1 0:00 xxx
24659 pts/1 0:00 xxx
24658 pts/1 0:00 xxx
24657 pts/1 0:00 xxx
24656 pts/1 0:00 xxx
24655 pts/1 0:00 xxx
24654 pts/1 0:00 xxx
24652 pts/1 0:00 xxx
24651 pts/1 0:00 xxx
24650 pts/1 0:00 xxx
24649 pts/1 0:00 xxx
24648 pts/1 0:00 xxx
24647 pts/1 0:00 xxx
24646 pts/1 0:00 xxx
24645 pts/1 0:00 xxx
24644 pts/1 0:00 xxx
24643 pts/1 0:00 xxx
24642 pts/1 0:00 xxx
24634 pts/1 0:00 xxx
24633 pts/1 0:00 xxx
24641 pts/1 0:00 xxx
24640 pts/1 0:00 xxx
24639 pts/1 0:00 xxx
24638 pts/1 0:00 xxx
24637 pts/1 0:00 xxx
24636 pts/1 0:00 xxx
24635 pts/1 0:00 xxx
24613 pts/1 0:00 xxx
24611 pts/1 0:00 xxx
# uname -a
SunOS hal 5.5.1 Generic sun4m sparc SUNW,SPARCstation-5
# exit
script done on Wed Oct 11 10:42:27 2000
The same fork() bomb will kill Linux 2.2.17 dead. We have to do
something.
Now, the SunWay(tm) seems to be to limit the number of forks/second
that can occur, giving the kernel some time to swap. This reduces
performance when you execute many programs from a shell. However,
most useful programs take some time to execute if they are truly
doing something useful. This may be the heuristic that wants to
be exploited both for forks and mallocs (sbrk / mmap). If a task
called these functions before some number of jiffy-counts had
expired, it would have to sleep until the expiration time. This
gives the kernel time to clean up.
I note that the directory cache is, for some reason, considered
so important that swap-space is used before the directory cache
is touched. There are a lot of things that should be done within
the kernel before you actually kill tasks, and some things that
should be done before you swap.
The whole idea of preventing attacks is to put an unreasonable
burden on the attacker. If the attacker's process gets slower and
slower, the more resources it consumes, in principle it could never
consume all available resources.
Given that the attacker is not really an attacker, but a Web Daemon,
if it gets slower as it starts to overload the system, the same
self-limiting occurs.
Cheers,
Dick Johnson
Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:18 EST