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

Groups > linux.kernel > #1658255 > unrolled thread

[PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 03:00 +0200
    Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before  using Theodore Ts'o <tytso@mit.edu> - 2017-06-06 05:10 +0200
      Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 06:00 +0200
        Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Eric Biggers <ebiggers3@gmail.com> - 2017-06-06 06:50 +0200
          Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 14:40 +0200
            Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 17:30 +0200
              Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Eric Biggers <ebiggers3@gmail.com> - 2017-06-06 19:30 +0200
                Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 19:40 +0200
            Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Theodore Ts'o <tytso@mit.edu> - 2017-06-06 19:10 +0200
              Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 19:30 +0200
              Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using Stephan Müller <smueller@chronox.de> - 2017-06-06 20:00 +0200
                Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-06 20:10 +0200
              Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2017-06-07 00:20 +0200
                Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Theodore Ts'o <tytso@mit.edu> - 2017-06-07 01:20 +0200
                Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using Stephan Müller <smueller@chronox.de> - 2017-06-07 07:10 +0200
                  Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Henrique de Moraes Holschuh <hmh@hmh.eng.br> - 2017-06-07 16:50 +0200
                  Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Theodore Ts'o <tytso@mit.edu> - 2017-06-07 23:30 +0200
                Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Daniel Micay <danielmicay@gmail.com> - 2017-06-07 19:10 +0200
                  Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Mark Rutland <mark.rutland@arm.com> - 2017-06-07 19:30 +0200
                    Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Daniel Micay <danielmicay@gmail.com> - 2017-06-08 06:00 +0200
              Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that  the RNG is ready before using Mark Rutland <mark.rutland@arm.com> - 2017-06-07 19:40 +0200
        Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before  using Kevin Easton <kevin@guarana.org> - 2017-06-08 14:10 +0200

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

#1660041 — Re: [kernel-hardening] Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 01:03:19PM -0400, Theodore Ts'o wrote:
> The other approach is to find a way to have initialized "seed" entropy
> which we can count on at every boot.  The problem is that this is very
> much dependent on how the bootloader works.  It's easy to say "store
> it in the kernel", but where the kernel is stored varies greatly from
> architecture to architecture.  In some cases, the kernel can stored in
> ROM, where it can't be modified at all.
> 
> It might be possible, for example, to store a cryptographic key in a
> UEFI boot-services variable, where the key becomes inaccessible after
> the boot-time services terminate.  But you also need either a reliable
> time-of-day clock, or a reliable counter which is incremented each
> time the system that boots, and which can't be messed with by an
> attacker, or trivially reset by a clueless user/sysadmin.

FWIW, EFI has an (optional) EFI_RNG_PROTOCOL, that we currently use to
seed the kernel's entropy pool. The EFI stub creates a config table with
the entropy, which the kernel reads.

This is re-seeded prior to kexec() to avoid the entropy being recycled.

See commits:

636259880a7e7d34 ("efi: Add support for seeding the RNG from a UEFI config table")
568bc4e87033d232 (" efi/arm*/libstub: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table")

Unfortunately, I beleive that support for the protocol is currently rare
in practice.

Thanks,
Mark.

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

#1661098 — Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using

On Tue, Jun 06, 2017 at 05:56:20AM +0200, Jason A. Donenfeld wrote:
> Hey Ted,
> 
> On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> > Note that crypto_rng_reset() is called by big_key_init() in
> > security/keys/big_key.c as a late_initcall().  So if we are on a
> > system where the crng doesn't get initialized until during the system
> > boot scripts, and big_key is compiled directly into the kernel, the
> > boot could end up deadlocking.
> >
> > There may be other instances of where crypto_rng_reset() is called by
> > an initcall, so big_key_init() may not be an exhaustive enumeration of
> > potential problems.  But this is an example of why the synchronous
> > API, although definitely much more convenient, can end up being a trap
> > for the unwary....
> 
> Thanks for pointing this out. I'll look more closely into it and see
> if I can figure out a good way of approaching this.

Would it work for wait_for_random_bytes() to include a

    WARN_ON(system_state < SYSTEM_RUNNING);

to catch those kinds of cases?

    - Kevin 

[toc] | [prev] | [standalone]

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

Back to top | Article view | linux.kernel

csiph-web