[lkml]   [2004]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] pid randomness
On Mon, 27 Dec 2004 19:39:01 GMT, "Pedro Venda (SYSADM)" said:

> I don't know if this has been discussed before... but I'd like to ask
> why isn't the pids randomized by default?

It's a pretty easy thing to do, actually. There's a patch for that
in Grsecurity, and I did one up myself a while ago...

One big problem that remains beyond my technical skill to fix - for the
32 bit machines, there's some funkiness in the /proc filesystem code
where it invents inode numbers based in the process ID that restrict the
effective value of max_pid to 64K. Unfortunately, if you're in the camp that
believes that randomizing the PID is useful at *all*, you probably want a
bigger space for the random number. So you can either fix that issue (and
whatever *OTHER* issues lurk after that one) or only deploy on 64 bit boxen...

A secondary issue that I've never been able to test is whether over time,
a "randomized" PID ends up sparsely dirtying the list of pidmap pages (so
you have enough pages to hold 4M PID bits, but only 1 or 2 bits per page
are actually set), or do the occasional long-lived processes end up essentially
leaving at least one process on each page anyhow? Any operational experience
on that one from the big-system guys?

At worst, 4M pids will take 128 4K pages (or equivalent for other page sizes) -
is that considered "unacceptable" on 64-bit boxes that want to do this?

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 14:09    [W:0.035 / U:2.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site