Re: /proc/sys/kernel/pid_max issues

[William Lee Irwin III <wli@holomorphy.com>]

Ingo Molnar writes:
>> it's getting quite spaghetti ... do we really want to handle
>> RESERVED_PID? There's no guarantee that any root daemon wont stray out
>> of the 1...300 PID range anyway, so if it has an exploitable PID race
>> bug then it's probably exploitable even without the RESERVED_PID
>> protection.

On Sun, Sep 12, 2004 at 11:20:29PM -0400, Albert Cahalan wrote:
> Purpose:
> 1. weak security enhancement
> 2. cosmetic (backwards, IMHO)
> 3. speed (avoid PIDs likely to be used)

Well, weak security enhancement translates to "nop" in my book, but
I guess if that's really what people were trying to arrange...


On Sun, Sep 12, 2004 at 11:20:29PM -0400, Albert Cahalan wrote:
> I'd much prefer LRU allocation. There are
> lots of system calls that take PID values.
> All such calls are hazardous. They're pretty
> much broken by design.
> Better yet, make a random choice from
> the 50% of PID space that has been least
> recently used.

I'd favor fully pseudorandom allocation over LRU or approximate LRU
allocation, as at least pseudorandom is feasible without large impacts
on resource scalability. OTOH the cache characteristics of pseudorandom
allocation are usually poor; perhaps hierarchically pseudorandom
allocation where one probes a sequence of cachelines of the bitmap
according to one PRNG, and within each cacheline probes a random
sequence of bits according to some other PRNG, would resolve that.


On Sun, Sep 12, 2004 at 11:20:29PM -0400, Albert Cahalan wrote:
> Another idea is to associate PIDs with users
> to some extent. You keep getting back the same
> set of PIDs unless the system runs low in some
> global pool and has to steal from one user to
> satisfy another.

The resource tracking and locking implications of this are disturbing.
Would fully pseudorandom allocation be acceptable?


On Sun, Sep 12, 2004 at 11:20:29PM -0400, Albert Cahalan wrote:
> BTW, since pid_max is now adjustable, reducing
> the default to 4 digits would make sense. Try a
> "ps j" to see the use. (column width changes if
> you change max_pid)

Is the maximum possible pid exported by the kernel somehow? Perhaps
it should be; the maximum number of decimal digits required to
represent PID_MAX_LIMIT (4*1024*1024) should suffice in all cases.
Perhaps you need to detect PID_MAX_LIMIT somehow?


-- wli