Date: Sat, 14 Sep 2002 17:06:32 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@FreeBSD.ORG> Subject: Re: Very important bug.. Message-ID: <3D83CF08.958FA87B@mindspring.com> References: <Pine.BSF.4.21.0209141615070.82711-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > apparently the code in libc in FreeBSD1.1 assumes that pids are < 32k > and CHECKS it.. :-) [ ... ] > I was thinking of adding a hook in the a.out entrypoints to > whack the pid down to a 32K universe just for fun. (flag in fork). > > when did we go up to "lots-o-pids"? and how far back did we check? The PIDs are also capable of being assigned randomly within the PID space, if a sysctl is set, in order to prevent their being predictable (you can call this "security through obscurity", if you don't understand math ;^), or you can call it "statistical protection"). Note that PIDs are limited to 99999 (PID_MAX in sys/proc.h; this value is not tunable at kernel compile time). Note that if you have the unpatched kqueue code (pre my patches to seperate the hint and the argument values), you have to keep this number under 0x000ffff, in any case, or kqueue quits working correctly on processes, and can actually result in a kernel panic when it effectively takes a modulo, and reference a proc struct that is not there for a queued event insertion. It's actually arguable that the code where the check is occuring is bogus, and is checking "< 0", rather than "== -1". That's not going to help you on code that is not going to be modified because it's no longer permitted to be maintained, but it does mean that these types of checks need to be fixed in the -current code, against similar future changes. The idea of a.out range limitation is pretty ugly, but it's likely the best option there is; I guess that turns the attempt to get a PID into an iterative process, with a clipping boundary, so that the randomization code doesn't have to change, and the limit doesn't end up covering a larger scope than it should. 8-(. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D83CF08.958FA87B>