Date: Thu, 14 Feb 2002 14:40:25 +0000 (GMT) From: Mike Silbersack <silby@silby.com> To: Gaspar Chilingarov <nm@web.am> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: fork rate limit Message-ID: <20020214142702.P11847-200000@patrocles.silby.com> In-Reply-To: <20020210185842.K29546-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1327964985-1013697578=:12083 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20020214143949.K12114@patrocles.silby.com> On Sun, 10 Feb 2002, Mike Silbersack wrote: > On Mon, 11 Feb 2002, Gaspar Chilingarov wrote: > > > Hi there! > > > > I've implemented suggested limits, and if you are interested, you can > > try attached patch, if it's OK, i will submit it to PR database. > > I finished looking at the patch, and I'm not impressed by it. It looks > like the patch I'm working on will work more effectively; I'll post or > commit it in a few days. > > Mike "Silby" Silbersack For those interested, here's the forkbomb countermeasure patch I've devised. It does three things: 1. Change the number of procs reserved for root from 1 to 10. Given how maxprocperuid is set in 4.5, this shouldn't matter much, but it's a safe change. 2. Limit the number of procs to an appropriate number. Previously, it was easy to set maxproc overly high by setting a large maxusers value. With this change, proc-related structures will only be able to consume about 1/2 of all system memory. Without this limitation, a high maxusers setting and a forkbomb could easily consume all system memory, leaving virtually no chance for the system to recover. 3. Penalize processes / users that hit their maxproc limit. Whenever a process tries to fork and that user's proc limit is hit, a tsleep of .5 seconds will occur. This change causes 1000 madly fork()ing processes into 1000 nicely sleeping processes if they continue to attempt to fork(). The testing I've done with this patch has proven it to be quite effective in protecting a system against a simple forkbomb, even if maxusers is set to inordinantly high values. Sysadmins who have already imposed low limits on their users will still be helped by change #3, as it ensures that less processor time will be wasted by continuous fork()ing. There are certainly a few remaining issues with more complex resource exhaustion attacks, but that can be dealt with in future patches. If you were interested in the fork rate limit thread, please give this patch a try to see if it helps in the forkbomb-like situations you've seen. Stable users: This won't compile as is for you. Change + tsleep(&forksleep, td->td_kse->ke_priority, "fork", hz / 2); to + tsleep(&forksleep, PUSER, "fork", hz / 2); Thanks, Mike "Silby" Silbersack --0-1327964985-1013697578=:12083 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="forklimits2.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20020214143938.P12083@patrocles.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="forklimits2.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL2tlcm4va2Vybl9mb3JrLmMg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmMNCi0tLSAvdXNyL3NyYy9z eXMub2xkL2tlcm4va2Vybl9mb3JrLmMJVHVlIEZlYiAxMiAwMDoyNDoxMyAy MDAyDQorKysgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9mb3JrLmMJVHVlIEZl YiAxMiAwMDoyNjowMiAyMDAyDQpAQCAtOTMsNiArOTMsOCBAQA0KIH07DQog I2VuZGlmDQogDQoraW50IGZvcmtzbGVlcDsgLyogUGxhY2UgZm9yIGZvcmsx KCkgdG8gc2xlZXAgb24uICovDQorDQogc3RhdGljIHZvaWQNCiBpbml0X2Zv cmtfbGlzdCh2b2lkICpkYXRhIF9fdW51c2VkKQ0KIHsNCkBAIC0yOTcsOCAr Mjk5LDggQEANCiAJICogcHJvY2Vzc2VzLCBtYXhwcm9jIGlzIHRoZSBsaW1p dC4NCiAJICovDQogCXVpZCA9IHAxLT5wX3VjcmVkLT5jcl9ydWlkOw0KLQlp ZiAoKG5wcm9jcyA+PSBtYXhwcm9jIC0gMSAmJiB1aWQgIT0gMCkgfHwgbnBy b2NzID49IG1heHByb2MpIHsNCi0JCXRhYmxlZnVsbCgicHJvYyIpOw0KKwlp ZiAoKG5wcm9jcyA+PSBtYXhwcm9jIC0gMTAgJiYgdWlkICE9IDApIHx8IG5w cm9jcyA+PSBtYXhwcm9jKSB7DQorCQl0c2xlZXAoJmZvcmtzbGVlcCwgdGQt PnRkX2tzZS0+a2VfcHJpb3JpdHksICJmb3JrIiwgaHogLyAyKTsNCiAJCXJl dHVybiAoRUFHQUlOKTsNCiAJfQ0KIAkvKg0KQEAgLTMxOCw2ICszMjAsNyBA QA0KIAkJICogQmFjayBvdXQgdGhlIHByb2Nlc3MgY291bnQNCiAJCSAqLw0K IAkJbnByb2NzLS07DQorCQl0c2xlZXAoJmZvcmtzbGVlcCwgdGQtPnRkX2tz ZS0+a2VfcHJpb3JpdHksICJmb3JrIiwgaHogLyAyKTsNCiAJCXJldHVybiAo RUFHQUlOKTsNCiAJfQ0KIA0KT25seSBpbiAvdXNyL3NyYy9zeXMva2Vybi86 IGtlcm5fZm9yay5jLm9yaWcNCmRpZmYgLXUgLXIgL3Vzci9zcmMvc3lzLm9s ZC9rZXJuL3N1YnJfcGFyYW0uYyAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX3Bh cmFtLmMNCi0tLSAvdXNyL3NyYy9zeXMub2xkL2tlcm4vc3Vicl9wYXJhbS5j CVR1ZSBGZWIgMTIgMDA6MjQ6MTYgMjAwMg0KKysrIC91c3Ivc3JjL3N5cy9r ZXJuL3N1YnJfcGFyYW0uYwlUdWUgRmViIDEyIDAwOjM1OjQwIDIwMDINCkBA IC0xMzEsNiArMTMxLDcgQEANCiB2b2lkDQogaW5pdF9wYXJhbTIoaW50IHBo eXNwYWdlcykNCiB7DQorCWludCBhdXRvbWF4cHJvYzsNCiANCiAJLyogQmFz ZSBwYXJhbWV0ZXJzICovDQogCW1heHVzZXJzID0gTUFYVVNFUlM7DQpAQCAt MTQ0LDExICsxNDUsMjUgQEANCiAJfQ0KIA0KIAkvKg0KKwkgKiBJbiBvcmRl ciB0byBtYWtlIHN1cmUgdGhhdCB0aGUgc3lzdGVtIGNhbm5vdCBiZSB0YWtl bg0KKwkgKiBkb3duIGJ5IHRvbyBtYW55IHByb2Nlc3Nlcywgd2UgbGltaXQg dGhlIG51bWJlciBvZg0KKwkgKiBwcm9jZXNzZXMgc28gdGhhdCBwcm9jZXNz LXJlbGF0ZWQgc3RydWN0dXJlcyBjYW4NCisJICogb25seSBvY2N1cHkgYXQg bW9zdCA1MCUgb2Ygc3lzdGVtIG1lbW9yeS4NCisJICoNCisJICogWFhYIC0g VGhlIDMySyB2YWx1ZSB3YXMgYXJyaXZlZCBhdCBleHBlcmltZW50YWxseSwN CisJICogYW5kIG1heSByZXF1aXJlIGNoYW5naW5nIGlmIHByZS1wcm9jIG1l bW9yeSB1c2FnZQ0KKwkgKiBjaGFuZ2VzIHN1YnN0YW50aWFsbHkuDQorCSAq Lw0KKwlhdXRvbWF4cHJvYyA9IChwaHlzcGFnZXMgLyAyKSAvICgzMjc2OCAv IFBBR0VfU0laRSk7DQorDQorCS8qDQogCSAqIFRoZSBmb2xsb3dpbmcgY2Fu IGJlIG92ZXJyaWRkZW4gYWZ0ZXIgYm9vdCB2aWEgc3lzY3RsLiAgTm90ZToN CiAJICogdW5sZXNzIG92ZXJyaWRlbiwgdGhlc2UgbWFjcm9zIGFyZSB1bHRp bWF0ZWx5IGJhc2VkIG9uIG1heHVzZXJzLg0KIAkgKi8NCiAJbWF4cHJvYyA9 IE5QUk9DOw0KIAlUVU5BQkxFX0lOVF9GRVRDSCgia2Vybi5tYXhwcm9jIiwg Jm1heHByb2MpOw0KKwlpZiAobWF4cHJvYyA+IGF1dG9tYXhwcm9jKQ0KKwkJ bWF4cHJvYyA9IGF1dG9tYXhwcm9jOw0KIAltYXhmaWxlcyA9IE1BWEZJTEVT Ow0KIAlUVU5BQkxFX0lOVF9GRVRDSCgia2Vybi5tYXhmaWxlcyIsICZtYXhm aWxlcyk7DQogCW1heHByb2NwZXJ1aWQgPSAobWF4cHJvYyAqIDkpIC8gMTA7 DQpPbmx5IGluIC91c3Ivc3JjL3N5cy9rZXJuLzogc3Vicl9wYXJhbS5jLm9y aWcNCg== --0-1327964985-1013697578=:12083-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020214142702.P11847-200000>