MT> Some Unices (AIX?) use random PID allocation to make PID
MT> prediction more difficult. Is this perceived to be worth
MT> it, or is it a non-issue?
It was straightforward to implement for a 2.0 kernel. My `ps f'
output looks like this:
PID COMMAND
22015 -bash
7960 \_ sh /home/junio/bin/common/x
1954 \_ xinit /home/junio/.xinitrc -- -auth /home/junio/.Xau
31489 \_ sh /home/junio/.xinitrc
4887 \_ emacs
78 | \_ ps f
14322 \_ fvwm95
4112 \_ sh /usr/lib/netscape/45/communicator/com
244 | \_ /usr/lib/netscape/45/communicator/co
14578 | \_ (dns helper)
10226 \_ /usr/X11R6/lib/X11/fvwm95//FvwmTaskBar 7
--- 2.0.37/kernel/fork.c 1998/06/03 22:17:50 1.1
+++ 2.0.37/kernel/fork.c 1999/06/17 06:46:29
@@ -21,6 +21,7 @@
#include <linux/malloc.h>
#include <linux/ldt.h>
#include <linux/smp.h>
+#include <linux/random.h>
#include <asm/segment.h>
#include <asm/system.h>
@@ -65,6 +66,10 @@
if (flags & CLONE_PID)
return current->pid;
+ if (last_pid) {
+ get_random_bytes (&last_pid, sizeof (last_pid));
+ last_pid &= ~0xffff8000;
+ }
repeat:
if ((++last_pid) & 0xffff8000)
last_pid=1;
The init launched upon kernel start-up must get pid 1 (it is a
long tradition, and user space init implementation relies on
it). The first if () statement in the above patch makes sure
that the first pid handed out by it is always 1.
2.2 and 2.3 kernels have some optimization where get_pid
function avoids trying to re-use pid less than 300 (I presume
that the reasoning behind this is because these low pids are
likely to be in use by long living daemon processes and it is
usually cheaper to just skip checking that range than trying to
conserve pid space) and a scheme to cache the result of previous
scan for available pid range, that depends on the fact that pid
is allocated linearly.
I do not see a clean way to implement the random pid allocation
without removing these optimization. One possibility would be
to make a bitmap of available pid pool (you do not have to make
bitmap for the entire 15- or 32-bit pid space; just pick a range
reasonably large enough to be sparse but still reasonably small
enough to fit on a page) and pick randomly from this pool when
you allocate a new pid. You need to replenish the pool using a
for_each_task loop similar to what is in get_pid when necessary.
But that would be a much bigger modification than the above
five-line patch, and the benefit of random pid allocation is
debatable.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/