Linux cryptographic layer development
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: noloader@gmail.com, 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>,
	Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH] random: silence compiler warnings and fix race
Date: Tue, 20 Jun 2017 05:36:42 -0400	[thread overview]
Message-ID: <20170620093642.3ri6dct5qkf7vhuc@thunk.org> (raw)
In-Reply-To: <CAHmME9rk-qrjJs6ZXQPoWV0sKBK_juq18tcE1h+pX8zSJJK1iQ@mail.gmail.com>

On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:
> > Suppressing all messages for all configurations cast a wider net than
> > necessary. Configurations that could potentially be detected and fixed
> > likely will go unnoticed. If the problem is not brought to light, then
> > it won't be fixed.
> 
> I more or less agree with you that we should just turn this on for all
> users and they'll just have to live with the spam and report odd
> entries, and overtime we'll fix all the violations.

Fix all the problems *how*?  If you are on an old system which doesn't
a hardware random number generator, and which doesn't have a high
resolution cycle counter, and may not have a lot of entropy easily
harvestable from the environment, there may not be a lot you can do.
Sure, you can pretend that the cache (which by the way is usually
determinstic) is ***so*** complicated that no one can figure it out,
and essentially pretend that you have entropy when you probably don't;
that just simply becomes a different way of handwaving and suppressing
the warning messages.

> But I think there's another camp that would mutiny in the face of this
> kind of hubris.

Blocking the boot for hours and hours until we have enough entropy to
initialize the CRNG is ***not*** an acceptable way of making the
warning messages go away.  Do that and the users **will** mutiny.

It's this sort of attitude which is why Linus has in the past said
that security people are sometimes insane....

						- Ted

  reply	other threads:[~2017-06-20  9:36 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
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 [this message]
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=20170620093642.3ri6dct5qkf7vhuc@thunk.org \
    --to=tytso@mit.edu \
    --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=mpe@ellerman.id.au \
    --cc=noloader@gmail.com \
    --cc=tglx@breakpoint.cc \
    --cc=torvalds@linux-foundation.org \
    /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