From: Stephan Mueller <smueller@chronox.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Ted Ts'o" <tytso@mit.edu>, lkml <linux-kernel@vger.kernel.org>,
Jeff Liu <jeff.liu@oracle.com>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH] avoid entropy starvation due to stack protection
Date: Thu, 13 Dec 2012 08:44:36 +0100 [thread overview]
Message-ID: <50C98764.6050104@chronox.de> (raw)
In-Reply-To: <20121212164321.a01c5641.akpm@linux-foundation.org>
On 13.12.2012 01:43:21, +0100, Andrew Morton
<akpm@linux-foundation.org> wrote:
Hi Andrew,
> On Tue, 11 Dec 2012 13:33:04 +0100
> Stephan Mueller <smueller@chronox.de> wrote:
>
>> Some time ago, I noticed the fact that for every newly
>> executed process, the function create_elf_tables requests 16 bytes of
>> randomness from get_random_bytes. This is easily visible when calling
>>
>> while [ 1 ]
>> do
>> cat /proc/sys/kernel/random/entropy_avail
>> sleep 1
>> done
> Please see
> http://ozlabs.org/~akpm/mmotm/broken-out/binfmt_elfc-use-get_random_int-to-fix-entropy-depleting.patch
>
> That patch is about one week from a mainline merge, btw.
Initially I was also thinking about get_random_int. But stack protection
depends on non-predictable numbers to ensure it cannot be defeated. As
get_random_int depends on MD5 which is assumed to be broken now, I
discarded the idea of using get_random_int.
Moreover, please consider that get_cycles is an architecture-specific
function that on some architectures only returns 0 (For all
architectures where this is implemented, you have no guarantee that it
increments as a high-resolution timer). So, the quality of
get_random_int is questionable IMHO for the use as a stack protector.
Also note, that other in-kernel users of get_random_bytes may be
converted to using the proposed kernel pool to avoid more entropy drainage.
Please note that the suggested approach of fully seeding a deterministic
RNG never followed by a re-seeding is used elsewhere (e.g. the OpenSSL
RNG). Therefore, I think the suggested approach is viable.
Ciao
Stephan
next prev parent reply other threads:[~2012-12-13 7:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-11 12:33 [PATCH] avoid entropy starvation due to stack protection Stephan Mueller
2012-12-12 10:48 ` Stephan Mueller
2012-12-13 0:43 ` Andrew Morton
2012-12-13 7:44 ` Stephan Mueller [this message]
2012-12-14 17:36 ` Stephan Mueller
2012-12-16 0:30 ` Theodore Ts'o
2012-12-16 12:46 ` Stephan Müller
2012-12-21 20:07 ` Ondřej Bílka
2012-12-22 19:29 ` Theodore Ts'o
2012-12-15 19:15 ` Ondřej Bílka
2012-12-15 22:59 ` Stephan Müller
2012-12-21 19:32 ` Ondřej Bílka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50C98764.6050104@chronox.de \
--to=smueller@chronox.de \
--cc=akpm@linux-foundation.org \
--cc=jeff.liu@oracle.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.