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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20121221193226.GA5867@domone>
Date:	Fri, 21 Dec 2012 20:32:27 +0100
From:	Ondřej Bílka <neleai@...nam.cz>
To:	Stephan Müller <smueller@...onox.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Ted Ts'o <tytso@....edu>, lkml <linux-kernel@...r.kernel.org>,
	Jeff Liu <jeff.liu@...cle.com>,
	Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] avoid entropy starvation due to stack protection

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/