, 2005-03-16
It's a sad day when an ancient fork bomb attack can still take down most of the latest Linux distributions.
Expand all |
Post comment
silly article
2005-03-17
Anonymous (4 replies)
Anonymous (4 replies)
silly article
2005-03-18
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security, Again
2005-03-17
Karyl Stein (1 replies)
Karyl Stein (1 replies)
Linux Kernel Security, Again
2005-03-17
Anonymous (3 replies)
Anonymous (3 replies)
Linux Kernel Security, Again
2005-03-17
Jason V. Miller (Author) (3 replies)
Jason V. Miller (Author) (3 replies)
Linux Kernel Security, Again
2005-03-17
mrsad (1 replies)
mrsad (1 replies)
Linux Kernel Security, Again
2005-03-17
Jason V. Miller (Author) (1 replies)
Jason V. Miller (Author) (1 replies)
Linux Kernel Security, Again
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
simple fork bomb?
2005-03-17
Anonymous (1 replies)
Anonymous (1 replies)
simple fork bomb?
2005-03-17
Jason V. Miller (Author) (3 replies)
Jason V. Miller (Author) (3 replies)
simple fork bomb?
2005-03-17
Anonymous (1 replies)
Anonymous (1 replies)
simple fork bomb?
2005-03-17
Jason V. Miller (Author) (1 replies)
Jason V. Miller (Author) (1 replies)
Intended use dictates the limits
2005-03-17
Erik Keller (1 replies)
Erik Keller (1 replies)
Intended use dictates the limits
2005-03-17
Jason V. Miller (Author) (4 replies)
Jason V. Miller (Author) (4 replies)
Linux Kernel Security, Again
2005-03-17
Anonymous (2 replies)
Anonymous (2 replies)
Linux Kernel Security, Again
2005-03-18
Anonymous (1 replies)
Anonymous (1 replies)
Linux Kernel Security, Again
2005-03-18
Gentoo User (1 replies)
Gentoo User (1 replies)
Linux Kernel Security, Again
2005-03-18
Another Gentoo User (2 replies)
Another Gentoo User (2 replies)
Debian IS vulnerable!
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
Linux only? perhaps across the board problem? Conflict of interest?
2005-03-18
glotfeltys@gmail.com (1 replies)
glotfeltys@gmail.com (1 replies)
Jason's opinion is too biased
2005-03-18
Anonymous (2 replies)
Anonymous (2 replies)
Take the first step author.
2005-03-18
EG (2 replies)
EG (2 replies)

would it be too far fetched to expect a kernel RPM to set this reasonable starting limit based on the number of processers, type, and the Mhz speed of them?
You can find this out by parsing /proc/cpuinfo... Just my 2 cents.
It should be easy to come up with reasonable limits with a little testing to figure out what the "magic" equation is. A good starting point for the pentium research might be:
p iteration * 32 * (mhz / 1000)* cpu count
This would leave you with:
P90: 1 * 32* .09 * 1= 1.44 (we'll go with a 32 here)
dual PIII 800: 3 * 32 * .8 * 2 = 153 (lets round to 256 or 128)
quad xeon 2Ghz: 4 * 32 * 2 * 8 (4*dual core)= 2048
I am just a simple code monkey so go easy on me lmfao. This isn't an exact science, so there may not be a right answer.
I think it's more important to set the limit than it is for it to be perfect for your particular situation.
l8,
anon
[ reply ]
Link to this comment: http://www.securityfocus.com/comments/columns/308/31172#31172