[lkml]   [2004]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: /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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.020 / U:35.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site