Re: [PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld wrote: > These functions are simple convenience wrappers that call > wait_for_random_bytes before calling the respective get_random_* > function. It may be advantageous to add a timeout, too. There's been a number of times I did not want to wait

Re: [kernel-hardening] 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 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 do

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

Hey Ted, On Tue, Jun 6, 2017 at 5:00 AM, Theodore Ts'o 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 com

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

On Tue, Jun 06, 2017 at 02:50:59AM +0200, Jason A. Donenfeld wrote: > Otherwise, we might be seeding the RNG using bad randomness, which is > dangerous. > > Cc: Herbert Xu > Signed-off-by: Jason A. Donenfeld > --- > crypto/rng.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > >

[PATCH v3 01/13] random: add synchronous API for the urandom pool

This enables users of get_random_{bytes,u32,u64,int,long} to wait until the pool is ready before using this function, in case they actually want to have reliable randomness. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 41 +++-- include/linux

[PATCH v3 02/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

These functions are simple convenience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.h | 25 + 3 file

[PATCH v3 03/13] random: invalidate batched entropy after crng init

It's possible that get_random_{u32,u64} is used before the crng has initialized, in which case, its output might not be cryptographically secure. For this problem, directly, this patch set is introducing the *_wait variety of functions, but even with that, there's a subtle issue: what happens to ou

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

Otherwise, we might be seeding the RNG using bad randomness, which is dangerous. Cc: Herbert Xu Signed-off-by: Jason A. Donenfeld --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/crypto/rng.c index f46dac5288b9..e042437e64b4 100644 --- a/

[PATCH v3 05/13] security/keys: ensure RNG is seeded before use

Otherwise, we might use bad random numbers which, particularly in the case of IV generation, could be quite bad. It makes sense to use the synchronous API here, because we're always in process context (as the code is littered with GFP_KERNEL and the like). However, we can't change to using a blocki

[PATCH v3 06/13] iscsi: ensure RNG is seeded before use

It's not safe to use weak random data here, especially for the challenge response randomness. Since we're always in process context, it's safe to simply wait until we have enough randomness to carry out the authentication correctly. While we're at it, we clean up a small memleak during an error co

[PATCH v3 07/13] ceph: ensure RNG is seeded before using

Ceph uses the RNG for various nonce generations, and it shouldn't accept using bad randomness. So, we wait for the RNG to be properly seeded. We do this by calling wait_for_random_bytes() in a function that is certainly called in process context, early on, so that all subsequent calls to get_random

[PATCH v3 10/13] net/neighbor: use get_random_u32 for 32-bit hash random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Signed-off-by: Jason A. Donenfeld Cc: David Miller --- net/core/nei

[PATCH v3 08/13] cifs: use get_random_u32 for 32-bit lock random

Using get_random_u32 here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is sometimes when this is used. Signed-off-by: Jason A. Donenfeld Cc: Steve French --- fs/cifs/cifsfs.c | 2 +- 1

[PATCH v3 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

This protocol uses lots of complex cryptography that relies on securely generated random numbers. Thus, it's important that the RNG is actually seeded before use. Fortuantely, it appears we're always operating in process context (there are many GFP_KERNEL allocations and other sleeping operations),

[PATCH v3 13/13] random: warn when kernel uses unseeded randomness

This enables an important dmesg notification about when drivers have used the crng without it being seeded first. Prior, these errors would occur silently, and so there hasn't been a great way of diagnosing these types of bugs for obscure setups. By adding this as a config option, we can leave it o

[PATCH v3 11/13] net/route: use get_random_int for random counter

Using get_random_int here is faster, more fitting of the use case, and just as cryptographically secure. It also has the benefit of providing better randomness at early boot, which is when many of these structures are assigned. Also, semantically, it's not really proper to have been assigning an a

[PATCH v3 09/13] rhashtable: use get_random_u32 for hash_rnd

This is much faster and just as secure. It also has the added benefit of probably returning better randomness at early-boot on systems with architectural RNGs. Signed-off-by: Jason A. Donenfeld Cc: Thomas Graf Cc: Herbert Xu --- lib/rhashtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deleti

[PATCH v3 00/13] Unseeded In-Kernel Randomness Fixes

As discussed in [1], there is a problem with get_random_bytes being used before the RNG has actually been seeded. The solution for fixing this appears to be multi-pronged. One of those prongs involves adding a simple blocking API so that modules that use the RNG in process context can just sleep (i

Re: [PATCH RFC v2 0/8] get_random_bytes_wait family of APIs

As this RFC series matures, all the changes are in this branch here, to look at: https://git.zx2c4.com/linux-dev/log/?h=jd/rng-blocker Ted -- there's one, in particular, that should probably be picked up regardless of the rest, and that's "random: invalidate batched entropy after crng init". Hope

Re: [PATCH RFC v2 5/8] security/keys: ensure RNG is seeded before use

On Mon, Jun 5, 2017 at 5:47 AM, Jason A. Donenfeld wrote: > - get_random_bytes(&key->serial, sizeof(key->serial)); > + ret = get_random_bytes_wait(&key->serial, > sizeof(key->serial)); This actually isn't okay at bootup, but I've got a different change for this sectio

Re: workqueue list corruption

Hello, On Sun, Jun 04, 2017 at 12:30:03PM -0700, Cong Wang wrote: > On Tue, Apr 18, 2017 at 8:08 PM, Samuel Holland wrote: > > Representative backtraces follow (the warnings come in sets). I have > > kernel .configs and extended netconsole output from several occurrences > > available upon reques

Re: [PATCH] crypto: brcm: fix spelling mistake: "fallbck" -> "fallback"

On Sun, Jun 4, 2017 at 2:29 PM, Colin King wrote: > From: Colin Ian King > > Trivial fix to spelling mistake in flow_log message > > Signed-off-by: Colin Ian King Good catch, thanks! Reviewed-by: Steve Lin > --- > drivers/crypto/bcm/cipher.c | 2 +- > 1 file changed, 1 insertion(+), 1 deleti