Messages in this thread | | | Subject | Re: [RFC] pid randomness | From | Valdis.Kletnieks@vt ... | Date | Mon, 27 Dec 2004 15:45:25 -0500 |
| |
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] | |