From owner-freebsd-security Sun Sep 12 20:21:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 92774154E9; Sun, 12 Sep 1999 20:21:21 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id XAA30870; Sun, 12 Sep 1999 23:19:14 -0400 (EDT) Date: Sun, 12 Sep 1999 23:19:13 -0400 (EDT) From: Bosko Milekic To: Stas Kisel Cc: avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) In-Reply-To: <199909091447.SAA24055@sonet.crimea.ua> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-750191660-937192753=:18795" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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-750191660-937192753=:18795 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello (again), On Thu, 9 Sep 1999, Stas Kisel wrote: !>> From avalon@cheops.anu.edu.au Thu Sep 9 16:17:27 1999 !> !>> > Probably it is not self-evident why we HAVE to drop this connection. !>> !>> So what if someone manages to crash a program due to a DOS attack ? !>> An easy one that comes to mind is syslogd. It's often stuck in disk-wait !>> and can easily be targetted with a large number of packets. !> !>1. If ever syslog used (or will use) TCP, it should drop the connection !>which is logging data too quickly. !>OS shouldn't kill process, only drop connection. So no crash. !>More examples? !> !>2. udp_drain() may either drop all packets or intellectually select !>"offending" socket and try to avoid deletion of "right" packets and !>simplifying spoofing. RFC allows 1st way, but 2-nd can improve OS. !> !>3. Another idea. Apart from the *_drain() method. Probably I ever will !>try to implement it somedays (quite low probability, though). !>Set TCP window in a packets according to really available kernel !>memory. Available memory should be distributed non-uniformly !>between maximum number of sockets. So 1-st socket has window= !>=64k-still_not_read_data, and 1024-th has window=MIN_WINDOW- !>-still_not_read_data. !>MIN_WINDOW should be determined for max efficiency. About 2k. !>Distribution can not be linear - it isapproximately like min(NORM*1/x,64k). !>Exactly it can be determined via functional equation. Something like !>\integral_0^maxsockets{dist(x)dx}=kernel_memory and several !>conditions. (sorry for my poor TeX). !> !>In a case of attack new sockets will be created with a very small !>window - about 2k. !> !>Please blame me as much as possible - probably I have missed some significant !>detail. !>Probably all this math suxx and the best is a "stair" function - !>somebody already works on lowering TCP window, if I didn't mistaken. !> !> !>-- !>Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game !>http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu !>+380(652)510222,230238 ; stas@crimea.edu stas@sonet.crimea.ua ; 2:460/54.4 !> These are all interesting ideas. However, when I initially posted regarding this, I was disappointed in seeing that we simply handle MGET()s, MGETHDR()s, and MCLALLOC()s by storing a null _even_ if we are M_WAIT. What basically ended up happening (and, the last time I checked, it's like this even in --CURRENT), is m_retry() -- or m_retryhdr() (this is in the case of no mbufs beings available) would simply panic(). I have produced patches (see attached -- they are seperated into two different patches, mbuf.patch which patches kern/uipc_mbuf.c and mbuf2.patch which patches sys/mbuf.h) that will basically tsleep() in the case of an M_WAIT and mbuf or mbuf cluster shortage. I wanted something that would make sure that we will get a non-NULL result when we called with M_WAIT. Obviously, this isn't the definite solution to the DoS problem that seemed to have become the main idea of discussion in this thread. However, I've kept that in mind, and I am now starting work (when time permits) on some code which will enable us to warn the network protocol module code that we're out of mbufs (or mbuf clusters) when the situation occurs. This way, if we can't get anything even with m_reclaim (which would be called from m_retry if we are M_WAIT), we could have the protocols figure out what to drop. I'm also aware of the possiblity of some people not liking the fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). Thus, I am open to modifying the diffs to add a counter and have the tsleep expire every once in a while so that finally, when the counter would expire, we would return a deffinate null _even_ if we are M_WAIT, but this can only be implemented if we make sure that ALL the MGET and company callers check for this (which would be annoying to do). Cheers, Bosko Milekic. --0-750191660-937192753=:18795 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mbuf.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mbuf.patch" LS0tIC91c3Ivc3JjL3N5cy9rZXJuLm9sZC91aXBjX21idWYuYwlXZWQgU2Vw ICA4IDIwOjQ1OjUwIDE5OTkNCisrKyAvdXNyL3NyYy9zeXMva2Vybi91aXBj X21idWYuYwlTdW4gU2VwIDEyIDIyOjQ0OjIzIDE5OTkNCkBAIC02MCw2ICs2 MCw4IEBADQogaW50CW1heF9oZHI7DQogaW50CW1heF9kYXRhbGVuOw0KIA0K K3N0YXRpYyBpbnQgbV9tYmFsbG9jX3dpZCA9IDAsIG1fY2xhbGxvY193aWQg PSAwOw0KKw0KIFNZU0NUTF9JTlQoX2tlcm5faXBjLCBLSVBDX01BWF9MSU5L SERSLCBtYXhfbGlua2hkciwgQ1RMRkxBR19SVywNCiAJICAgJm1heF9saW5r aGRyLCAwLCAiIik7DQogU1lTQ1RMX0lOVChfa2Vybl9pcGMsIEtJUENfTUFY X1BST1RPSERSLCBtYXhfcHJvdG9oZHIsIENUTEZMQUdfUlcsDQpAQCAtMTUz LDYgKzE1NSw1NyBAQA0KIAlyZXR1cm4gKDEpOw0KIH0NCiANCisvKg0KKyAq IEZ1bmN0aW9uIHVzZWQgZm9yIHdhaXRpbmcgb24gc29tZSBtYnVmIHRvIGJl IGZyZWVkIGFuZCwgdXBvbiB3YWtldXAsDQorICogdG8gZ28gZ2V0IHRoYXQg bWJ1ZiBhbmQgdXNlIGl0Lg0KKyAqLw0KK3N0cnVjdCBtYnVmICoNCittX21i YWxsb2Nfd2FpdChjYWxsZXIsIHR5cGUpDQorCWludCBjYWxsZXI7DQorCWlu dCB0eXBlOw0KK3sNCisJc3RydWN0IG1idWYgKnA7DQorDQorUmV0cnlGZXRj aDoNCisJLyogU2xlZXAgaGVyZSB1bnRpbCBzb21ldGhpbmcncyBhdmFpbGFi bGUuICovDQorCW1fbWJhbGxvY193aWQrKzsNCisJdHNsZWVwKCZtX21iYWxs b2Nfd2lkLCBQVk0sICJtYmFsbGMiLCAwKTsNCisJDQorCS8qDQorCSAqIE5v dyB0aGF0IHdlICh0aGluaykgdGhhdCB3ZSd2ZSBnb3Qgc29tZXRoaW5nLCB3 ZSB3aWxsIHJlZG8gYW4NCisJICogTUdFVCwgYnV0IGF2b2lkIGdldHRpbmcg aW50byBhbm90aGVyIGluc3RhbmNlIG9mIG1fbWJhbGxvY193YWl0KCkNCisJ ICogV2UgZG8gdGhpcyBieSBkZWZpbmluZyB0aGlzIGZ1bmN0aW9uIGFzIG51 bGwuDQorCSAqLw0KKyNkZWZpbmUgbV9tYmFsbG9jX3dhaXQoY2FsbGVyLHR5 cGUpIChzdHJ1Y3QgbWJ1ZiAqKTAgDQorCWlmIChjYWxsZXIgPT0gTUdFVF9D KSB7DQorCQlNR0VUKHAsTV9XQUlULHR5cGUpOw0KKwl9IGVsc2Ugew0KKwkJ TUdFVEhEUihwLE1fV0FJVCx0eXBlKTsNCisJfQ0KKyN1bmRlZiBtX21iYWxs b2Nfd2FpdA0KKyANCisJLyoNCisJICogSWYgd2UgZmFpbCB5ZXQgYWdhaW4s IGdvIGJhY2sgdG8gc2xlZXBpbmcuDQorCSAqIFhYWCBQZXJoYXBzIHdlIHNo b3VsZCBpbXBsZW1lbnQgYSBsaW1pdCBzb21ld2hlcmUgaGVyZS4gDQorCSAq Lw0KKwlpZiAocCA9PSBOVUxMKQ0KKwkJZ290byBSZXRyeUZldGNoOw0KKw0K KwlyZXR1cm4gKHApOw0KK30NCisNCisvKg0KKyAqIEZ1bmN0aW9uIHVzZWQg dG8gd2FrZXVwIHNsZWVwZXJzIHdhaXRpbmcgZm9yIG1idWZzLi4uDQorICov DQordm9pZA0KK21fbWJhbGxvY193YWtldXAodm9pZCkNCit7DQorCWlmICht X21iYWxsb2Nfd2lkKSB7DQorCQltX21iYWxsb2Nfd2lkID0gMDsNCisJCXdh a2V1cCgmbV9tYmFsbG9jX3dpZCk7DQorCX0NCit9DQorDQogI2lmIE1DTEJZ VEVTID4gUEFHRV9TSVpFDQogc3RhdGljIGludCBpX3dhbnRfbXlfbWNsOw0K IA0KQEAgLTI0Miw2ICsyOTUsNTMgQEANCiB9DQogDQogLyoNCisgKiBUaGlz IGZ1bmN0aW9uIHdpbGwgYmUgdXNlZCB0byBzbGVlcCBhbmQgd2FpdCB1bnRp bCB3ZSBoYXZlIGEgZnJlZQ0KKyAqIG1idWYgY2x1c3Rlci4gVGhpcyBpcyBm b3IgY2FsbGVycyB3aXRoIE1fV0FJVCB3aG8nZCBsaWtlIHRvIGF2b2lkDQor ICogcmV0dXJuaW5nIE5VTEwgYW5kIHRha2UgdGhlIGhlYXQsIHdhaXRpbmcg KHdoaWNoIGlzIGxvZ2ljYWxseSB3aGF0DQorICogc2hvdWxkIGhhcHBlbiBh bnl3YXkgd2l0aCBhbiBNX1dBSVQpLg0KKyAqLw0KK2NhZGRyX3QNCittX2Ns YWxsb2Nfd2FpdCh2b2lkKQ0KK3sNCisJY2FkZHJfdCBwOw0KKw0KK1JldHJ5 Q2x1c3Q6DQorCS8qIFNsZWVwIGhlcmUgdW50aWwgc29tZXRoaW5nJ3MgYXZh aWxhYmxlLiAqLw0KKwltX2NsYWxsb2Nfd2lkKys7DQorCXRzbGVlcCgmbV9j bGFsbG9jX3dpZCwgUFZNLCAibWNsYWxjIiwgMCk7DQorDQorCS8qDQorCSAq IE5vdyB0aGF0IHdlICh0aGluaykgdGhhdCB3ZSd2ZSBnb3Qgc29tZXRoaW5n LCB3ZSB3aWxsIHJlZG8gYW5kDQorCSAqIE1HRVQsIGJ1dCBhdm9pZCBnZXR0 aW5nIGludG8gYW5vdGhlciBpbnN0YW5jZSBvZiBtX2NsYWxsb2Nfd2FpdCgp DQorCSAqIFdlIGRvIHRoaXMgYnkgZGVmaW5pbmcgdGhpcyBmdW5jdGlvbiBh cyBudWxsLg0KKwkgKi8NCisjZGVmaW5lIG1fY2xhbGxvY193YWl0KCkgKGNh ZGRyX3QpMA0KKwlNQ0xBTExPQyhwLE1fV0FJVCk7DQorI3VuZGVmIG1fY2xh bGxvY193YWl0DQorDQorCS8qDQorCSAqIElmIHdlIGZhaWwgeWV0IGFnYWlu LCBnbyBiYWNrIHRvIHNsZWVwaW5nLg0KKwkgKiBYWFggUGVyaGFwcyB3ZSBz aG91bGQgaW1wbGVtZW50IGEgbGltaXQgc29tZXdoZXJlIGhlcmUuDQorCSAq Lw0KKwlpZiAocCA9PSBOVUxMKQ0KKwkJZ290byBSZXRyeUNsdXN0Ow0KKw0K KwlyZXR1cm4gKHApOw0KK30NCisNCisvKg0KKyAqIEZ1bmN0aW9uIHVzZWQg dG8gd2FrZXVwIHNsZWVwZXJzIHdhaXRpbmcgZm9yIG1idWYgY2x1c3RlcnMu Li4NCisgKi8NCit2b2lkDQorbV9jbGFsbG9jX3dha2V1cCh2b2lkKQ0KK3sN CisJaWYgKG1fY2xhbGxvY193aWQpIHsNCisJCW1fY2xhbGxvY193aWQgPSAw Ow0KKwkJd2FrZXVwKCZtX2NsYWxsb2Nfd2lkKTsNCisJfQ0KK30NCisNCisv Kg0KICAqIFdoZW4gTUdFVCBmYWlscywgYXNrIHByb3RvY29scyB0byBmcmVl IHNwYWNlIHdoZW4gc2hvcnQgb2YgbWVtb3J5LA0KICAqIHRoZW4gcmUtYXR0 ZW1wdCB0byBhbGxvY2F0ZSBhbiBtYnVmLg0KICAqLw0KQEAgLTI2MSwxMiAr MzYxLDkgQEANCiAjdW5kZWYgbV9yZXRyeQ0KIAlpZiAobSAhPSBOVUxMKSB7 DQogCQltYnN0YXQubV93YWl0Kys7DQotCX0gZWxzZSB7DQotCQlpZiAoaSA9 PSBNX0RPTlRXQUlUKQ0KLQkJCW1ic3RhdC5tX2Ryb3BzKys7DQotCQllbHNl DQotCQkJcGFuaWMoIk91dCBvZiBtYnVmIGNsdXN0ZXJzIik7DQotCX0NCisJ fSBlbHNlIA0KKwkJbWJzdGF0Lm1fZHJvcHMrKzsNCisNCiAJcmV0dXJuICht KTsNCiB9DQogDQpAQCAtMjg5LDEyICszODYsOSBAQA0KICN1bmRlZiBtX3Jl dHJ5aGRyDQogCWlmIChtICE9IE5VTEwpIHsNCiAJCW1ic3RhdC5tX3dhaXQr KzsNCi0JfSBlbHNlIHsNCi0JCWlmIChpID09IE1fRE9OVFdBSVQpDQotCQkJ bWJzdGF0Lm1fZHJvcHMrKzsNCi0JCWVsc2UNCi0JCQlwYW5pYygiT3V0IG9m IG1idWYgY2x1c3RlcnMiKTsNCi0JfQ0KKwl9IGVsc2UgDQorCQltYnN0YXQu bV9kcm9wcysrOw0KKw0KIAlyZXR1cm4gKG0pOw0KIH0NCiANCg== --0-750191660-937192753=:18795 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="mbuf2.patch" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="mbuf2.patch" LS0tIC91c3Ivc3JjL3N5cy9zeXMub2xkL21idWYuaAkJU2F0IFNlcCAxMSAx OToxMDo0NCAxOTk5DQorKysgL3Vzci9zcmMvc3lzL3N5cy9tYnVmLmgJCVN1 biBTZXAgMTIgMjI6NDQ6NDQgMTk5OQ0KQEAgLTE1Myw2ICsxNTMsMTMgQEAN CiAjZGVmaW5lCU1fRE9OVFdBSVQJMQ0KICNkZWZpbmUJTV9XQUlUCQkwDQog DQorLyogDQorICogRmxhZ3MgdG8gcGFzcyB0byB0aGUgKl93YWl0IGZ1bmN0 aW9ucyAod2hlbiB3ZSBoYXZlIHRvIHdhaXQgZm9yIGFuDQorICogbWJ1ZiB0 byBiZSBmcmVlZCkuDQorICovDQorI2RlZmluZSBNR0VUX0MJCTENCisjZGVm aW5lIE1HRVRIRFJfQwkyDQorDQogLyogRnJlZWxpc3RzOg0KICAqDQogICog Tm9ybWFsIG1idWYgY2x1c3RlcnMgYXJlIG5vcm1hbGx5IHRyZWF0ZWQgYXMg Y2hhcmFjdGVyIGFycmF5cw0KQEAgLTIwMyw3ICsyMTAsOCBAQA0KIAkJc3Bs eChfbXMpOyBcDQogCX0gZWxzZSB7IFwNCiAJCXNwbHgoX21zKTsgXA0KLQkJ KG0pID0gbV9yZXRyeSgoaG93KSwgKHR5cGUpKTsgXA0KKwkJaWYgKCgobSk9 bV9yZXRyeSgoaG93KSwgKHR5cGUpKSk9PU5VTEwgJiYgKGhvdyk9PU1fV0FJ VCkgXA0KKwkJCShtKSA9IG1fbWJhbGxvY193YWl0KE1HRVRfQywodHlwZSkp OyBcDQogCX0gXA0KIH0NCiANCkBAIC0yMjMsNyArMjMxLDggQEANCiAJCXNw bHgoX21zKTsgXA0KIAl9IGVsc2UgeyBcDQogCQlzcGx4KF9tcyk7IFwNCi0J CShtKSA9IG1fcmV0cnloZHIoKGhvdyksICh0eXBlKSk7IFwNCisJCWlmICgo KG0pPW1fcmV0cnloZHIoKGhvdyksKHR5cGUpKSk9PU5VTEwgJiYgKGhvdyk9 PU1fV0FJVCkgXA0KKwkJCShtKSA9IG1fbWJhbGxvY193YWl0KE1HRVRIRFJf QywodHlwZSkpOyBcDQogCX0gXA0KIH0NCiANCkBAIC0yMzUsMTYgKzI0NCwy MCBAQA0KICAqIE1DTEZSRUUgcmVsZWFzZXMgYSByZWZlcmVuY2UgdG8gYSBj bHVzdGVyIGFsbG9jYXRlZCBieSBNQ0xBTExPQywNCiAgKiBmcmVlaW5nIHRo ZSBjbHVzdGVyIGlmIHRoZSByZWZlcmVuY2UgY291bnQgaGFzIHJlYWNoZWQg MC4NCiAgKi8NCi0jZGVmaW5lCU1DTEFMTE9DKHAsIGhvdykgXA0KLQlNQlVG TE9DSyggXA0KLQkgIGlmIChtY2xmcmVlID09IDApIFwNCisjZGVmaW5lCU1D TEFMTE9DKHAsIGhvdykgeyBcDQorCWludCBfbXMgPSBzcGxpbXAoKTsgXA0K KwlpZiAobWNsZnJlZSA9PSAwKSBcDQogCQkodm9pZCltX2NsYWxsb2MoMSwg KGhvdykpOyBcDQotCSAgaWYgKCgocCkgPSAoY2FkZHJfdCltY2xmcmVlKSAh PSAwKSB7IFwNCisJaWYgKCgocCkgPSAoY2FkZHJfdCltY2xmcmVlKSAhPSAw KSB7IFwNCiAJCSsrbWNscmVmY250W210b2NsKHApXTsgXA0KIAkJbWJzdGF0 Lm1fY2xmcmVlLS07IFwNCiAJCW1jbGZyZWUgPSAoKHVuaW9uIG1jbHVzdGVy ICopKHApKS0+bWNsX25leHQ7IFwNCi0JICB9IFwNCi0JKQ0KKwkJc3BseChf bXMpOyBcDQorIAl9IGVsc2UgaWYgKChob3cpID09IE1fV0FJVCkgeyBcDQor CQlzcGx4KF9tcyk7IFwNCisJCShwKSA9IG1fY2xhbGxvY193YWl0KCk7IFwN CisJfSBcDQorfQ0KIA0KICNkZWZpbmUJTUNMR0VUKG0sIGhvdykgXA0KIAl7 IE1DTEFMTE9DKChtKS0+bV9leHQuZXh0X2J1ZiwgKGhvdykpOyBcDQpAQCAt MjYzLDYgKzI3Niw3IEBADQogCQkoKHVuaW9uIG1jbHVzdGVyICopKHApKS0+ bWNsX25leHQgPSBtY2xmcmVlOyBcDQogCQltY2xmcmVlID0gKHVuaW9uIG1j bHVzdGVyICopKHApOyBcDQogCQltYnN0YXQubV9jbGZyZWUrKzsgXA0KKwkJ KHZvaWQpbV9jbGFsbG9jX3dha2V1cCgpOyBcDQogCSAgfSBcDQogCSkNCiAN CkBAIC0yODQsNiArMjk4LDcgQEANCiAJCQkJKCh1bmlvbiBtY2x1c3RlciAq KShwKSktPm1jbF9uZXh0ID0gbWNsZnJlZTsgXA0KIAkJCQltY2xmcmVlID0g KHVuaW9uIG1jbHVzdGVyICopKHApOyBcDQogCQkJCW1ic3RhdC5tX2NsZnJl ZSsrOyBcDQorCQkJCSh2b2lkKW1fY2xhbGxvY193YWtldXAoKTsgXA0KIAkJ CX0gXA0KIAkJfSBcDQogCSAgfSBcDQpAQCAtMjkyLDYgKzMwNyw3IEBADQog CSAgbWJzdGF0Lm1fbXR5cGVzW01UX0ZSRUVdKys7IFwNCiAJICAobSktPm1f bmV4dCA9IG1tYmZyZWU7IFwNCiAJICBtbWJmcmVlID0gKG0pOyBcDQorCSAg KHZvaWQpbV9tYmFsbG9jX3dha2V1cCgpOyBcDQogCSkNCiANCiAvKg0KQEAg LTQwOCwxNiArNDI0LDIwIEBADQogc3RydWN0CW1idWYgKm1fZ2V0aGRyIF9f UCgoaW50LCBpbnQpKTsNCiBzdHJ1Y3QJbWJ1ZiAqbV9wcmVwZW5kIF9fUCgo c3RydWN0IG1idWYgKixpbnQsaW50KSk7DQogc3RydWN0CW1idWYgKm1fcHVs bHVwIF9fUCgoc3RydWN0IG1idWYgKiwgaW50KSk7DQorc3RydWN0CW1idWYg Km1fbWJhbGxvY193YWl0IF9fUCgoaW50LGludCkpOw0KIHN0cnVjdAltYnVm ICptX3JldHJ5IF9fUCgoaW50LCBpbnQpKTsNCiBzdHJ1Y3QJbWJ1ZiAqbV9y ZXRyeWhkciBfX1AoKGludCwgaW50KSk7DQogc3RydWN0CW1idWYgKm1fc3Bs aXQgX19QKChzdHJ1Y3QgbWJ1ZiAqLGludCxpbnQpKTsNCiB2b2lkCW1fYWRq IF9fUCgoc3RydWN0IG1idWYgKiwgaW50KSk7DQogdm9pZAltX2NhdCBfX1Ao KHN0cnVjdCBtYnVmICosc3RydWN0IG1idWYgKikpOw0KK3ZvaWQJbV9tYmFs bG9jX3dha2V1cCBfX1AoKHZvaWQpKTsNCit2b2lkCW1fY2xhbGxvY193YWtl dXAgX19QKCh2b2lkKSk7DQogaW50CW1fbWJhbGxvYyBfX1AoKGludCwgaW50 KSk7DQogaW50CW1fY2xhbGxvYyBfX1AoKGludCwgaW50KSk7DQogdm9pZAlt X2NvcHliYWNrIF9fUCgoc3RydWN0IG1idWYgKiwgaW50LCBpbnQsIGNhZGRy X3QpKTsNCiB2b2lkCW1fY29weWRhdGEgX19QKChzdHJ1Y3QgbWJ1ZiAqLGlu dCxpbnQsY2FkZHJfdCkpOw0KIHZvaWQJbV9mcmVlbSBfX1AoKHN0cnVjdCBt YnVmICopKTsNCitjYWRkcl90CW1fY2xhbGxvY193YWl0IF9fUCgodm9pZCkp Ow0KICNlbmRpZiAvKiBLRVJORUwgKi8NCiANCiAjZW5kaWYgLyogIV9TWVNf TUJVRl9IXyAqLw0K --0-750191660-937192753=:18795-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message