Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1656327 > unrolled thread

get_random_bytes returns bad randomness before seeding is complete

Back to article view | Back to linux.kernel

Contents

  get_random_bytes returns bad randomness before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-02 17:10 +0200
    Re: get_random_bytes returns bad randomness before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-02 18:00 +0200
      Re: get_random_bytes returns bad randomness before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-02 18:50 +0200
      Re: [kernel-hardening] Re: get_random_bytes returns bad randomness  before seeding is complete Daniel Micay <danielmicay@gmail.com> - 2017-06-02 19:50 +0200
        Re: [kernel-hardening] Re: get_random_bytes returns bad randomness  before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-02 19:50 +0200
        Re: [kernel-hardening] Re: get_random_bytes returns bad randomness  before seeding is complete Kees Cook <keescook@chromium.org> - 2017-06-02 21:00 +0200
    Re: get_random_bytes returns bad randomness before seeding is  complete Theodore Ts'o <tytso@mit.edu> - 2017-06-02 19:30 +0200
      Re: get_random_bytes returns bad randomness before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-02 19:50 +0200
        Re: get_random_bytes returns bad randomness before seeding is  complete Theodore Ts'o <tytso@mit.edu> - 2017-06-02 21:10 +0200
          Re: get_random_bytes returns bad randomness before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-03 02:00 +0200
            Re: [kernel-hardening] Re: get_random_bytes returns bad randomness  before seeding is complete Sandy Harris <sandyinchina@gmail.com> - 2017-06-03 02:30 +0200
            [PATCH RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-03 04:40 +0200
            [PATCH RFC 0/3] get_random_bytes seed blocking "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-03 04:40 +0200
              [PATCH RFC 1/3] random: add synchronous API for the urandom pool "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-03 04:40 +0200
              [PATCH RFC 3/3] random: warn when kernel uses unseeded randomness "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-03 04:40 +0200
            Re: get_random_bytes returns bad randomness before seeding is  complete Theodore Ts'o <tytso@mit.edu> - 2017-06-03 07:10 +0200
              Re: get_random_bytes returns bad randomness before seeding is complete "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-03 14:40 +0200
                Re: get_random_bytes returns bad randomness before seeding is complete Sandy Harris <sandyinchina@gmail.com> - 2017-06-03 23:50 +0200
                  Re: get_random_bytes returns bad randomness before seeding is complete Jeffrey Walton <noloader@gmail.com> - 2017-06-04 01:00 +0200
                    Re: [kernel-hardening] Re: get_random_bytes returns bad randomness  before seeding is complete Daniel Micay <danielmicay@gmail.com> - 2017-06-04 02:00 +0200
                    Re: get_random_bytes returns bad randomness before seeding is complete Stephan Müller <smueller@chronox.de> - 2017-06-04 08:00 +0200
    Re: get_random_bytes returns bad randomness before seeding is complete Stephan Müller <smueller@chronox.de> - 2017-06-04 07:50 +0200
      Re: get_random_bytes returns bad randomness before seeding is complete Jeffrey Walton <noloader@gmail.com> - 2017-06-04 08:00 +0200
    Re: get_random_bytes returns bad randomness before seeding is complete Stephan Müller <smueller@chronox.de> - 2017-06-04 08:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1656997

Am Sonntag, 4. Juni 2017, 00:54:39 CEST schrieb Jeffrey Walton:

Hi Jeffrey,

> On Sat, Jun 3, 2017 at 5:45 PM, Sandy Harris <sandyinchina@gmail.com> wrote:
> > ...
> > Of course this will fail on systems with no high-res timer. Are there
> > still some of those? It might be done in about 1000 times as long on a
> > system that lacks the realtime library's nanosecond timer but has the
> > Posix standard microsecond timer, implying a delay time in the
> > milliseconds. Would that be acceptable in those cases?
> 
> A significant portion of the use cases should include mobile devices.
> Device sales outnumbered desktop and server sales several years ago.
> 
> Many devices are sensor rich. Even the low-end ones come with
> accelorometers for gaming. A typical one has 3 or 4 sensors, and
> higher-end ones have 7 or 8 sensors. An Evo 4G has 7 of them.
> 

I think those devices are covered with the kernels 4.8+. That kernel uses 
solely interrupts as noise source for the first stage we talk about here.

Not having done any particular measurements with the latest kernels on mobile 
devices, but based on my experience with my LRNG assessment, I could fathom 
that mobile devices have a fully seeded ChaCha20 DRNG before user space 
starts.

Just to give an illustration: I have a Lenovo T540 which receives more than 
256 interrupts before late_initcall. On all system with a high-res timer, each 
interrupt will give more than one bit of entropy. Conversely, on my MacBook 
Pro 2015,  at late_initcall the kernel received less than 100 interrupts. In a 
KVM guest with very little devices, I also have some 100 interrupts before 
late_initcall. These measurements are taken with the same kernel and same 
kernel configs.

Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1656993

Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld:

Hi Jason,

> 
> Alternatively, I'm open to other solutions people might come up with.

How about stirring in some data from the Jitter RNG that we have in the kernel 
already and that is used for the DRBG in case get_random_bytes has 
insufficient entropy? Yes, two kernel developers said that this RNG is 
useless, where in fact a lot of hardware and even crypto folks say that this 
approach has merits.

In any case, it cannot destroy the (not present) entropy at boot time anyway. 
Thus, take some 32, 48 or 64 bytes from it right at the start of the kernel, 
and we should be better (from the view point of quite some folks) or not worse 
off (view point of two developers here).

As this RNG does not depend on any in-kernel facility, it is always available 
at any time.

PS: I could revive a patch adding this to random.c that I sent long ago if 
desired.

Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1656996

On Sun, Jun 4, 2017 at 1:48 AM, Stephan Müller <smueller@chronox.de> wrote:
> Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld:
>
>> Alternatively, I'm open to other solutions people might come up with.
>
> How about stirring in some data from the Jitter RNG that we have in the kernel
> already and that is used for the DRBG in case get_random_bytes has
> insufficient entropy? Yes, two kernel developers said that this RNG is
> useless, where in fact a lot of hardware and even crypto folks say that this
> approach has merits.

Almost anything has to be better than (1) silent failures, and (2)
draining the little entropy available when the generators are starting
and trying to become operational.

The [negative] use case for (2) is systemd. See, for example,
https://github.com/systemd/systemd/issues/4167.

Jeff

[toc] | [prev] | [next] | [standalone]

#1657000

Am Freitag, 2. Juni 2017, 16:59:56 CEST schrieb Jason A. Donenfeld:

Hi Jason,

> Alternatively, I'm open to other solutions people might come up with.

One addition, there is an issue (I would call it a bug) in random.c before 4.8 
where the nonblocking_pool is not reseeded during early boot even though 
entropy may be available. That issue aggravates early boot time entropy issues 
for user and kernel land.

I have not heard about accepting or rejecting it, so I am wondering how 
patches go into random.c at all.

[1] https://patchwork.kernel.org/patch/9620431/

Ciao
Stephan

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web