Messages in this thread | | | Date | Mon, 13 Sep 2004 07:27:52 -0700 | From | William Lee Irwin III <> | Subject | Re: /proc/sys/kernel/pid_max issues |
| |
On Mon, 2004-09-13 at 03:42, William Lee Irwin III wrote: >> The resource tracking and locking implications of this are disturbing. >> Would fully pseudorandom allocation be acceptable?
On Mon, Sep 13, 2004 at 10:11:29AM -0400, Albert Cahalan wrote: > There's no point. > LRU reduces accidents that don't involve an attacker. > Strong crypto random can make some attacks a bit harder. > OpenBSD does this. It doesn't work well enough to bother > with if the implementation is problematic; there's not > much you can do while avoiding 64-bit or 128-bit PIDs. > Pseudorandom is 100% useless. > Per-user PID recycling would make it much harder for > an attacker to grab a specific PID. Perhaps the attacker > knows that a sched_setscheduler call is coming, and he > has a way to make the right process restart or crash. > Normally, this lets him get SCHED_FIFO or somesuch. > With per-user PID recycling, it would be difficult for > him to grab the desired PID.
I'd suggest pushing for 64-bit+ pid's, then. IIRC most of the work there is in userspace (the in-kernel part is trivial).
-- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |