Messages in this thread | | | Date | Wed, 11 Oct 2000 11:02:00 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler) |
| |
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/
| |