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


Groups > linux.kernel > #1658334

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

From "Jason A. Donenfeld" <Jason@zx2c4.com>
Newsgroups linux.kernel
Subject Re: [PATCH v3 04/13] crypto/rng: ensure that the RNG is ready before using
Date 2017-06-06 06:00 +0200
Message-ID <tPdOV-3t1-1@gated-at.bofh.it> (permalink)
References <tPb0J-1BU-3@gated-at.bofh.it> <tPb0J-1BU-19@gated-at.bofh.it> <tPd2y-3dl-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Indeed you're right -- that we have to be really quite careful every
time we use the synchronous API. For this reason, I separated things
out into the wait_for_random_bytes and then the wrapper around
wait_for_random_bytes+get_random_bytes of get_random_bytes_wait. The
idea here would be that drivers could place a single
wait_for_random_bytes at some userspace entry point -- a configuration
ioctl, for example -- and then try to ensure that all calls to
get_random_bytes are ordered _after_ that wait_for_random_bytes call.
While this pattern doesn't fix all cases of unseeded get_random_bytes
calls -- we'll need to do some module loading order cleverness for
that, as we discussed in the other thread -- I think this pattern will
fix an acceptable amount of call sites, as seen here in this patchset,
that it makes it worthwhile. Having it, too, I think would encourage
other new drivers to think about when their calls to get_random_bytes
happens, and if it's possible for them to defer it until after a
userspace-blocking call to wait_for_random_bytes.

Anyway, I'll look into and fix up the problem you mentioned. Looking
forward to your feedback on the other patches here.

Regards,
Jason

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[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

csiph-web