Re: [PATCH] avoid entropy starvation due to stack protection

["Ondřej Bílka" <neleai@seznam.cz>]

On Sat, Dec 15, 2012 at 11:59:46PM +0100, Stephan Müller wrote:
> Am 15.12.2012 20:15, schrieb Ondřej Bílka:
> >Why not use nonblocking pool and seed nonblocking pool only with half of
> >collected entropy to get /dev/random in almost all practical scenarios
> >nonblocking?
> 
> I would not recommend changing /dev/urandom. First, we would change
> the characteristic of a kernel interface a lot of user space
> cryptographic components rely on. 
How it would change characteristic more than swapping a hard disk for a
ssd? Should we display a message "Please type more slowly to maintain
kernel interface."?

> According to Linus that is
> typically a no-go. Moreover, the question can be raised, where do we
> pick the number of 50%, why not 30% or 70%, why (re)seeding it at
> all?
And does this argument make any difference?
> 
> Also, let us assume we pick 50% and we leave the create_elf_tables
> function as is (i.e. it pulls from get_random_bytes), I fear that we
> do not win at all. Our discussed problem is the depletion of the
> entropy via nonblocking_pool due to every execve() syscall requires
> 128 bits of data from nonblocking_pool. Even if we seed
> nonblocking_pool more rarely, we still deplete the entropy of the
> input_pool and thus deplete the entropy we want for cryptographic
> purposes a particular user has.
This is only correct upto thus part. As blocking pool would get full
after 8096 bytes would be generated, stayed full until needed and won't 
be affected by input pool. As long as we would generate at least twice
entropy than blocking pool consumes we would be fine.