From: Michael Ellerman <mpe@ellerman.id.au>
To: Theodore Ts'o <tytso@mit.edu>, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: tglx@breakpoint.cc, David Miller <davem@davemloft.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Eric Biggers <ebiggers3@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kernel-hardening@lists.openwall.com,
Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Subject: Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race
Date: Tue, 20 Jun 2017 16:59:49 +1000 [thread overview]
Message-ID: <871sqfuot6.fsf@concordia.ellerman.id.au> (raw)
In-Reply-To: <20170620060344.ngbnzg2mz5hvq4kw@thunk.org>
Theodore Ts'o <tytso@mit.edu> writes:
> On Mon, Jun 19, 2017 at 10:57:18PM +0200, Jason A. Donenfeld wrote:
>>
>> With rc6 already released and rc7 coming up, I'd really appreciate you
>> stepping in here and either ACKing the above commit, or giving your
>> two cents about it in case I need to roll something different.
>
> I actually had set up an earlier version of your patch for on Saturday
> while I was in Beijing. (Like Linus, I'm attending the LinuxCon China
> conference Monday and Tuesday.) I had even created the signed tag,
> but I didn't send the pull request to Linus because I was waiting to
> see about how discussions over the locking strategy and the spammy log
> messages on PowerPC was going to get resolved.
>
> I've since respun the commit to reflect your newer patch (see the
> random_for_linus_stable tag on random.git) and rebased the dev branch
> on top of that. Please take a look and comment.
>
> The other open issue I want to resolve before sending a pull request
> this week is whether we want to change the default for
> CONFIG_WARN_UNSEEDED_RANDOM so that the answer is 'n'.
Yes please.
> It *is* spammy for PowerPC, because they aren't getting their CRNG
*some* powerpc machines ...
> initialized quickly enough, so several userspace processes are getting
> fork/exec'ed with an uninitialized CRNG. That being said, it is a
> valid warning because it means that the initial stack canary for the
> first couple of PowerPC processes are being created without a fully
> initialized CRNG, which may mean that an attacker might be able to
> circumvent the stack canary on the first couple of processes. So that
> could potentially be a real security issue on Power. OTOH, most Power
> users aren't going to be able to do anything about the fact the stack
> canaries of the system daemons started during early boot don't have
> strong randomness, so perhaps we should disable the warning by
> default.
powerpc supports a wide range of hardware platforms, some of which are
10-15 years old, and don't have a hardware RNG.
Is there anything we can do on those machines? Seems like our only
option would be to block the boot while some more "entropy" builds up,
but that's unlikely to be popular with users.
On our newer machines (>= Power8) we have a hardware RNG which we wire
up to arch_get_random_seed_long(), so on those machines the warnings
would be valid, because they'd indicate a bug.
So I think it should be up to arches to decide whether this is turned on
via their defconfigs, and the default should be 'n' because a lot of old
hardware won't be able to do anything useful with the warnings.
cheers
next prev parent reply other threads:[~2017-06-20 6:59 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-07 23:25 [PATCH v5 00/13] Unseeded In-Kernel Randomness Fixes Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 01/13] random: invalidate batched entropy after crng init Jason A. Donenfeld
2017-06-14 19:28 ` Sebastian Andrzej Siewior
2017-06-14 22:33 ` Jason A. Donenfeld
2017-06-16 8:31 ` Sebastian Andrzej Siewior
2017-06-16 12:12 ` Jason A. Donenfeld
2017-06-16 14:36 ` Sebastian Andrzej Siewior
2017-06-14 22:45 ` [PATCH] random: silence compiler warnings and fix race Jason A. Donenfeld
2017-06-16 14:35 ` Sebastian Andrzej Siewior
2017-06-17 0:39 ` Jason A. Donenfeld
2017-06-19 7:45 ` Sebastian Andrzej Siewior
2017-06-19 20:55 ` Jason A. Donenfeld
2017-06-20 6:44 ` Sebastian Andrzej Siewior
2017-06-19 20:57 ` Jason A. Donenfeld
2017-06-20 6:03 ` Theodore Ts'o
2017-06-20 6:27 ` [kernel-hardening] " Joel Stanley
2017-06-20 6:59 ` Michael Ellerman [this message]
2017-06-20 8:14 ` Jason A. Donenfeld
2017-06-20 8:33 ` Jeffrey Walton
2017-06-20 8:53 ` Jason A. Donenfeld
2017-06-20 9:36 ` Theodore Ts'o
2017-06-20 9:49 ` Jeffrey Walton
2017-06-20 17:50 ` [kernel-hardening] " Sandy Harris
2017-06-20 18:14 ` Kees Cook
2017-06-20 20:09 ` Jason A. Donenfeld
2017-06-20 9:49 ` Jason A. Donenfeld
2017-06-20 23:38 ` Theodore Ts'o
2017-06-20 23:54 ` Jason A. Donenfeld
2017-06-21 0:03 ` [PATCH] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
2017-06-21 0:12 ` Kees Cook
2017-06-21 6:06 ` Michael Ellerman
2017-06-21 20:38 ` [kernel-hardening] " Theodore Ts'o
2017-06-22 0:04 ` Jason A. Donenfeld
2017-06-21 23:50 ` [PATCH] random: silence compiler warnings and fix race Jeffrey Walton
2017-06-07 23:25 ` [PATCH v5 02/13] random: add synchronous API for the urandom pool Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 04/13] security/keys: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-07 23:25 ` [PATCH v5 05/13] crypto/rng: ensure that the RNG is ready before using Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 06/13] iscsi: ensure RNG is seeded before use Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 07/13] ceph: ensure RNG is seeded before using Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 08/13] cifs: use get_random_u32 for 32-bit lock random Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 09/13] rhashtable: use get_random_u32 for hash_rnd Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 10/13] net/neighbor: use get_random_u32 for 32-bit hash random Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 11/13] net/route: use get_random_int for random counter Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use Jason A. Donenfeld
2017-06-07 23:26 ` [PATCH v5 13/13] random: warn when kernel uses unseeded randomness Jason A. Donenfeld
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=871sqfuot6.fsf@concordia.ellerman.id.au \
--to=mpe@ellerman.id.au \
--cc=Jason@zx2c4.com \
--cc=davem@davemloft.net \
--cc=ebiggers3@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@breakpoint.cc \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox