Date: Sun, 12 Sep 1999 23:19:13 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Stas Kisel <stas@sonet.crimea.ua> Cc: avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) Message-ID: <Pine.OSF.4.05.9909122304470.18795-300000@oracle.dsuper.net> In-Reply-To: <199909091447.SAA24055@sonet.crimea.ua>
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-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: <Pine.OSF.4.05.9909122319130.18795@oracle.dsuper.net>
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: <Pine.OSF.4.05.9909122319131.18795@oracle.dsuper.net>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9909122304470.18795-300000>