[lkml]   [2000]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFC/PATCH: Random pid generation

    On 13 Jan 2000, Peter Samuelson wrote:

    > [Alan Cox]
    > > > Random pids just slow the process down. Its an argument for writing
    > > > decent code.
    > Chris Evans <> writes:
    > > Random pids in a 32 bit space would take an average of ~1 random
    > > number generation to calculate per fork. That can't be too slow can
    > > it?
    > By "slow the process down" Alan was referring to the process of
    > exploiting a /tmp race. You didn't eliminate the race, in other words,
    > you just obfuscated it.

    Ah, thank you.

    Obfuscation is not to be discounted, however. Imagine a 64 bit pid_t. Now,
    the race would, on average, take longer than the remaining lifetime of the
    universe to exploit.

    A 32 bit pid_t is more interesting (and plausible). Assuming a _signed_
    pid_t, a rather high rate of 1000 exploit attempts/second, and a 100% race
    success when the right pid is guessed

    .. you take on average 11.5 days to exploit. At 100% CPU. That's not going
    to go unnoticed.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.018 / U:33.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site