From owner-freebsd-arch Wed Dec 1 7:20:48 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 67EF514D0F for ; Wed, 1 Dec 1999 07:20:45 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA27595 for ; Wed, 1 Dec 1999 16:20:25 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA77210 for freebsd-arch@freebsd.org; Wed, 1 Dec 1999 16:20:25 +0100 (MET) Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 8442314D0F; Wed, 1 Dec 1999 07:20:13 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id CA04B1CA0; Wed, 1 Dec 1999 23:19:55 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Sheldon Hearn Cc: arch@freebsd.org, "Jordan K. Hubbard" , Matthew Dillon , billf@freebsd.org Subject: Re: cvs commit: src/sys/i386/conf files.i386 src/sys/kern kern_fork.c src/sys/libkern arc4random.c src/sys/sys libkern.h In-Reply-To: Message from Sheldon Hearn of "Wed, 01 Dec 1999 10:31:34 +0200." <50754.944037094@axl.noc.iafrica.com> Date: Wed, 01 Dec 1999 23:19:55 +0800 From: Peter Wemm Message-Id: <19991201151955.CA04B1CA0@overcee.netplex.com.au> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Sheldon Hearn wrote: > > > On Mon, 29 Nov 1999, Jordan K. Hubbard wrote: > > > Not being able to predict pids (for useful purposes) would fall under > > the definition of "negative impact" for a number of admins. > > Doesn't the new behaviour come with a sysctl knob (off by default) for > controlling it? If so, what's all the fuss? At the risk of continuing the debate, what I would prefer would be a sysctl to define the range of a random increment to the nextpid, so there is an element of randomness still but you're going to get a steadily increasing set of pid's still. So, sysctl -w kern.randompid=1000 would get you an increment of between 1 and 1000 for each new process. You still end up with some randomness, but you still get increasing pids. The sysctl would accept a value between 0 (present behavior) and PID_MAX - 100. (I've added a wraparound and protected the pid's less than 100 like before). Using totally random pid's where the nextpid could be anywhere from 0 through 100000 means that the pidchecked code is getting very heavily excercised. That's a *lot* of list walking. Suggested patch at: http://overcee.netplex.com.au/~peter/randompid.diff A quick example where a process forks 5 children and prints the pid's: peter@t8000[11:16pm]-107> ./pid 0: child pid 242 1: child pid 243 2: child pid 244 3: child pid 245 4: child pid 246 root@t8000:[11:16pm]-100# sysctl -w kern.randompid=100 0 -> 100 peter@t8000[11:16pm]-108> ./pid 0: child pid 427 1: child pid 524 2: child pid 571 3: child pid 623 4: child pid 664 1000 or 10000 would be better for the more paranoid. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message