Messages in this thread | | | Date | Thu, 13 Jan 2000 20:20:00 +0000 (GMT) | From | Chris Evans <> | Subject | Re: 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 <chris@ferret.lmh.ox.ac.uk> 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.
Cheers Chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |