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

Hi Eric, On Tue, Jun 6, 2017 at 6:44 AM, Eric Biggers wrote: > I don't think big_key even needs randomness at init time. The 'big_key_rng' > could just be removed and big_key_gen_enckey() changed to call > get_random_bytes(). (Or get_random_bytes_wait(), I guess; it's only

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

Hi Eric, On Tue, Jun 6, 2017 at 6:44 AM, Eric Biggers wrote: > I don't think big_key even needs randomness at init time. The 'big_key_rng' > could just be removed and big_key_gen_enckey() changed to call > get_random_bytes(). (Or get_random_bytes_wait(), I guess; it's only reachable > via the

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

On Tue, Jun 6, 2017 at 9:45 AM, Greg Kroah-Hartman wrote: > If it's needed no matter what, can you make it the first patch in the > series? And does it need to go to any older kernels as well? I believe it does belong in older kernels too. I'll work out precisely

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

On Tue, Jun 6, 2017 at 9:45 AM, Greg Kroah-Hartman wrote: > If it's needed no matter what, can you make it the first patch in the > series? And does it need to go to any older kernels as well? I believe it does belong in older kernels too. I'll work out precisely which one those are and note it

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

On Tue, Jun 6, 2017 at 12:08 PM, David Howells <dhowe...@redhat.com> wrote: > Jason A. Donenfeld <ja...@zx2c4.com> wrote: > >> + key->serial = get_random_u32() >> 1; > > If this may sleep, it must be interruptible. That won't sleep. I could have

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

On Tue, Jun 6, 2017 at 12:08 PM, David Howells wrote: > Jason A. Donenfeld wrote: > >> + key->serial = get_random_u32() >> 1; > > If this may sleep, it must be interruptible. That won't sleep. I could have made it get_random_u32_wait(), but we'd get i

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

On Tue, Jun 6, 2017 at 7:11 AM, Jeffrey Walton <noloa...@gmail.com> wrote: > On Mon, Jun 5, 2017 at 8:50 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: >> These functions are simple convenience wrappers that call >> wait_for_random_bytes before calling the respecti

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

On Tue, Jun 6, 2017 at 7:11 AM, Jeffrey Walton wrote: > 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

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,

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

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

condition. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "Nicholas A. Bellinger" <n...@linux-iscsi.org> Cc: Lee Duncan <ldun...@suse.com> Cc: Chris Leech <cle...@redhat.com> --- drivers/target/iscsi/iscsi_target_auth.c | 14 +++--- drivers/targ

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

condition. Signed-off-by: Jason A. Donenfeld Cc: "Nicholas A. Bellinger" Cc: Lee Duncan Cc: Chris Leech --- drivers/target/iscsi/iscsi_target_auth.c | 14 +++--- drivers/target/iscsi/iscsi_target_login.c | 22 ++ 2 files changed, 25 insertions(+), 11

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

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Marcel Holtmann <mar...@holtmann.org> Cc: Gustavo P

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

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg --- net/bluetooth

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

an atomic_t in this way before, even if in practice it works fine. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Miller <da...@davemloft.net> --- net/ipv4/route.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/r

[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 <ja...@zx2c4.com> Cc: Thomas Graf <tg...@suug.ch> Cc: Herbert Xu <herb...@gondor.apana.o

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

an atomic_t in this way before, even if in practice it works fine. Signed-off-by: Jason A. Donenfeld Cc: David Miller --- net/ipv4/route.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 655d9eebe43e..11e001a42094 100644 --- a/net/ipv4

[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

[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 <ja...@zx2c4.com> Cc: David

[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

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

`. This will ensure that the curious see the messages while others don't have to. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.c | 15 +-- lib/Kconfig.debug | 16 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/driver

[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 <herb...@gondor.apana.org.au> Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/

[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 <ja...@zx2c4.com> Cc: Steve French

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

introduce a simple rwlock for this invalidation. Since it's only during this awkward transition period, after things are all set up, we stop using it, so that it doesn't have an impact on performance. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.

[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 <ja...@zx2c4.com> --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.

[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

[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 03/13] random: invalidate batched entropy after crng init

introduce a simple rwlock for this invalidation. Since it's only during this awkward transition period, after things are all set up, we stop using it, so that it doesn't have an impact on performance. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 34

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

`. This will ensure that the curious see the messages while others don't have to. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 15 +-- lib/Kconfig.debug | 16 2 files changed, 29 insertions(+), 2 deletions(-) diff --git a/drivers/char/random.c b/drivers

[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

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

to get_random_bytes are necessarily acceptable. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Ilya Dryomov <idryo...@gmail.com> Cc: "Yan, Zheng" <z...@redhat.com> Cc: Sage Weil <s...@redhat.com> --- net/ceph/ceph_common.c | 6 +- 1 file changed, 5 insertions(+

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

to get_random_bytes are necessarily acceptable. Signed-off-by: Jason A. Donenfeld Cc: Ilya Dryomov Cc: "Yan, Zheng" Cc: Sage Weil --- net/ceph/ceph_common.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c index 4f

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

a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: David Howells <dhowe...@redhat.com> Cc: Mi

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

a blocking function in key serial allocation, because this will block booting in some configurations, so here we use the more appropriate get_random_u32, which will use RDRAND if available. Signed-off-by: Jason A. Donenfeld Cc: David Howells Cc: Mimi Zohar Cc: David Safford --- security/keys

[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 <ja...@zx2c4.com> --- drivers/char/random.c

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

u32,u64}, so this series makes those changes in a few places. It's useful here, since on some architectures that delivers better early randomness. Jason A. Donenfeld (13): random: add synchronous API for the urandom pool random: add get_random_{bytes,u32,u64,int,long,once}_wait fam

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

u32,u64}, so this series makes those changes in a few places. It's useful here, since on some architectures that delivers better early randomness. Jason A. Donenfeld (13): random: add synchronous API for the urandom pool random: add get_random_{bytes,u32,u64,int,long,once}_wait fam

[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

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".

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".

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 <ja...@zx2c4.com> wrote: > - get_random_bytes(>serial, sizeof(key->serial)); > + ret = get_random_bytes_wait(>serial, > sizeof(key->serial)); This actually isn't okay at bootup, but

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(>serial, sizeof(key->serial)); > + ret = get_random_bytes_wait(>serial, > sizeof(key->serial)); This actually isn't okay at bootup, but I've got a different ch

[PATCH RFC v2 2/8] 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 <ja...@zx2c4.com> --- include/linux/net.h| 2 ++ include/linux/once.h | 2 ++ include/linux/random.

[PATCH RFC v2 2/8] 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

[PATCH RFC v2 5/8] 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). Signed-off-by: Jason A. Donenfeld <

[PATCH RFC v2 5/8] 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). Signed-off-by: Jason A. Donenfeld Cc

[PATCH RFC v2 8/8] ceph: ensure RNG is seeded before using

to get_random_bytes are necessarily acceptable. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Ilya Dryomov <idryo...@gmail.com> Cc: "Yan, Zheng" <z...@redhat.com> Cc: Sage Weil <s...@redhat.com> --- net/ceph/ceph_common.c | 6 +- 1 file changed, 5 insertions(+

[PATCH RFC v2 8/8] ceph: ensure RNG is seeded before using

to get_random_bytes are necessarily acceptable. Signed-off-by: Jason A. Donenfeld Cc: Ilya Dryomov Cc: "Yan, Zheng" Cc: Sage Weil --- net/ceph/ceph_common.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/net/ceph/ceph_common.c b/net/ceph/ceph_common.c index 4f

[PATCH RFC v2 6/8] iscsi: ensure RNG is seeded before use

condition. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "Nicholas A. Bellinger" <n...@linux-iscsi.org> Cc: Lee Duncan <ldun...@suse.com> Cc: Chris Leech <cle...@redhat.com> --- drivers/target/iscsi/iscsi_target_auth.c | 14 +++--- drivers/targ

[PATCH RFC v2 3/8] random: warn when kernel uses unseeded randomness

it on by default, so that we learn where these issues happen, in the field, will still allowing some people to turn it off, if they really know what they're doing and do not want the log entries. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.c | 3 +-- lib/Kconfig

[PATCH RFC v2 6/8] iscsi: ensure RNG is seeded before use

condition. Signed-off-by: Jason A. Donenfeld Cc: "Nicholas A. Bellinger" Cc: Lee Duncan Cc: Chris Leech --- drivers/target/iscsi/iscsi_target_auth.c | 14 +++--- drivers/target/iscsi/iscsi_target_login.c | 22 ++ 2 files changed, 25 insertions(+), 11

[PATCH RFC v2 3/8] random: warn when kernel uses unseeded randomness

it on by default, so that we learn where these issues happen, in the field, will still allowing some people to turn it off, if they really know what they're doing and do not want the log entries. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 3 +-- lib/Kconfig.debug | 15

[PATCH RFC v2 7/8] bluetooth/smp: ensure RNG is properly seeded before ECDH use

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Marcel Holtmann <mar...@holtmann.org> Cc: Gustavo P

[PATCH RFC v2 4/8] 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 <herb...@gondor.apana.org.au> Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/rng.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/crypto/rng.c b/

[PATCH RFC v2 4/8] 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

[PATCH RFC v2 7/8] bluetooth/smp: ensure RNG is properly seeded before ECDH use

the RNG initialization has been interrupted, rather than later, so we call wait_for_random_bytes() at the top, so that later on the call to get_random_bytes() is acceptable. Signed-off-by: Jason A. Donenfeld Cc: Marcel Holtmann Cc: Gustavo Padovan Cc: Johan Hedberg --- net/bluetooth

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

ble and non-interruptable waiting and also timeouts, we just support the case that people will actually use: ordinary interruptable waiting. This simplifies the API a bit. - This patch set now has a few examples of where it might be useful. Jason A. Donenfeld (8): random: add synchron

[PATCH RFC v2 1/8] 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 <ja...@zx2c4.com> --- drivers/char/random.c

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

ble and non-interruptable waiting and also timeouts, we just support the case that people will actually use: ordinary interruptable waiting. This simplifies the API a bit. - This patch set now has a few examples of where it might be useful. Jason A. Donenfeld (8): random: add synchron

[PATCH RFC v2 1/8] 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

[PATCH net-next v10 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

ecent MIPS changes that give it a separate IRQ stack, so that I could experience some worst-case situations. I found that limiting it to 24 layers deep yielded a good stack usage with room for safety, as well as being much deeper than any driver actually ever creates. Signed-off-by: Jason A. Don

[PATCH net-next v10 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Steffen Klassert <steffen.klass...@secunet.com> Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: "David S. Miller" <da...@davemloft.net> --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 20

[PATCH net-next v10 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow

ecent MIPS changes that give it a separate IRQ stack, so that I could experience some worst-case situations. I found that limiting it to 24 layers deep yielded a good stack usage with room for safety, as well as being much deeper than any driver actually ever creates. Signed-off-by: Jason A. Don

[PATCH net-next v10 2/5] ipsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Cc: Steffen Klassert Cc: Herbert Xu Cc: "David S. Miller" --- net/ipv4/ah4.c | 8 ++-- net/ipv4/esp4.c | 20 +--- net/ipv6/ah6.c | 8 ++-- net/ipv6/esp6.c | 20 +--- 4 files changed, 38 insertions(+), 18

[PATCH net-next v10 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Acked-by: David Howells <dhowe...@redhat.com> --- net/rxrpc/rxkad.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 1bb9b2ccc267..29fe20ad04aa 1006

[PATCH net-next v10 3/5] rxrpc: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Acked-by: David Howells --- net/rxrpc/rxkad.c | 19 ++- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c index 1bb9b2ccc267..29fe20ad04aa 100644 --- a/net/rxrpc/rxkad.c +++ b/net/rxrpc/rxkad.c

[PATCH net-next v10 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Sabrina Dubroca <s...@queasysnail.net> --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index 91642fd87cd1..b79513b

[PATCH net-next v10 4/5] macsec: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Cc: Sabrina Dubroca --- drivers/net/macsec.c | 13 +++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index 91642fd87cd1..b79513b8322f 100644 --- a/drivers/net/macsec.c +++ b/drivers/net

[PATCH net-next v10 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Reviewed-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> Cc: "Michael S. Tsirkin" <m...@redhat.com> Cc: Jason Wang <jasow...@redhat.com> --- drivers/net/virtio_net.c | 9 +++-- 1 file changed, 7 i

[PATCH net-next v10 0/5] Avoiding stack overflow in skb_to_sgvec

all; and 2) When the passed in skbuff is too deeply nested. So, the first patch in this series handles the issues with skb_to_sgvec directly, and the remaining ones then handle the call sites. Jason A. Donenfeld (5): skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ipsec: check ret

[PATCH net-next v10 5/5] virtio_net: check return value of skb_to_sgvec always

Signed-off-by: Jason A. Donenfeld Reviewed-by: Sergei Shtylyov Cc: "Michael S. Tsirkin" Cc: Jason Wang --- drivers/net/virtio_net.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 3e9246cc49c3..57

[PATCH net-next v10 0/5] Avoiding stack overflow in skb_to_sgvec

all; and 2) When the passed in skbuff is too deeply nested. So, the first patch in this series handles the issues with skb_to_sgvec directly, and the remaining ones then handle the call sites. Jason A. Donenfeld (5): skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow ipsec: check ret

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 3, 2017 at 7:04 AM, Theodore Ts'o wrote: > has been pretty terrible? > This kind of "my shit doesn't stink, but yours does", is not > The reason why I keep harping on this is because I'm concerned about > an absolutist attitude towards technical design, where the good

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 3, 2017 at 7:04 AM, Theodore Ts'o wrote: > has been pretty terrible? > This kind of "my shit doesn't stink, but yours does", is not > The reason why I keep harping on this is because I'm concerned about > an absolutist attitude towards technical design, where the good is the Moving

[PATCH RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family

These functions are simple convience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- include/linux/random.h | 30 ++ 1 file changed, 30 insertions(+) diff

[PATCH RFC 2/3] random: add get_random_{bytes,u32,u64,int,long}_wait family

These functions are simple convience wrappers that call wait_for_random_bytes before calling the respective get_random_* function. Signed-off-by: Jason A. Donenfeld --- include/linux/random.h | 30 ++ 1 file changed, 30 insertions(+) diff --git a/include/linux

[PATCH RFC 3/3] random: warn when kernel uses unseeded randomness

it on by default, so that we learn where these issues happen, in the field, will still allowing some people to turn it off, if they really know what they're doing and do not want the log entries. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.c | 3 +-- lib/Kconfig

[PATCH RFC 3/3] random: warn when kernel uses unseeded randomness

it on by default, so that we learn where these issues happen, in the field, will still allowing some people to turn it off, if they really know what they're doing and do not want the log entries. Signed-off-by: Jason A. Donenfeld --- drivers/char/random.c | 3 +-- lib/Kconfig.debug | 15

[PATCH RFC 0/3] get_random_bytes seed blocking

forward with polish and with integrating it into a fix for a few currently buggy get_random_bytes use cases. Jason A. Donenfeld (3): random: add synchronous API for the urandom pool random: add get_random_{bytes,u32,u64,int,long}_wait family random: warn when kernel uses unseeded randomness

[PATCH RFC 1/3] 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 <ja...@zx2c4.com> --- drivers/char/random.c

[PATCH RFC 0/3] get_random_bytes seed blocking

forward with polish and with integrating it into a fix for a few currently buggy get_random_bytes use cases. Jason A. Donenfeld (3): random: add synchronous API for the urandom pool random: add get_random_{bytes,u32,u64,int,long}_wait family random: warn when kernel uses unseeded randomness

[PATCH RFC 1/3] 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 | 46 -- include

Re: get_random_bytes returns bad randomness before seeding is complete

Hi Ted, Based on the tone of your last email, before I respond to your individual points, I think it's worth noting that the intent of this thread is to get a sampling of opinions of the issue of get_random_bytes, so that I can write a patch that fixes this issue (or a series of issues) using

Re: get_random_bytes returns bad randomness before seeding is complete

Hi Ted, Based on the tone of your last email, before I respond to your individual points, I think it's worth noting that the intent of this thread is to get a sampling of opinions of the issue of get_random_bytes, so that I can write a patch that fixes this issue (or a series of issues) using

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 7:41 PM, Daniel Micay wrote: > One of the early uses is initializing the stack canary value for SSP in > very early boot. If that blocks, it's going to be blocking nearly > anything else from happening. > > On x86, that's only the initial canary since

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 7:41 PM, Daniel Micay wrote: > One of the early uses is initializing the stack canary value for SSP in > very early boot. If that blocks, it's going to be blocking nearly > anything else from happening. > > On x86, that's only the initial canary since the per-task canaries

Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 7:26 PM, Theodore Ts'o wrote: > I tried making /dev/urandom block. > So if you're a security focused individual who is kvetching > And if we're breaking Yes yes, bla bla, predictable response. I don't care. Your API is still broken. Excuses excuses. Yes,

Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 2, 2017 at 7:26 PM, Theodore Ts'o wrote: > I tried making /dev/urandom block. > So if you're a security focused individual who is kvetching > And if we're breaking Yes yes, bla bla, predictable response. I don't care. Your API is still broken. Excuses excuses. Yes, somebody needs to

Re: get_random_bytes returns bad randomness before seeding is complete

Further investigations: if the whack-a-mole approach is desirable, perhaps many of those get_random_bytes calls should be converted to get_blocking_random_bytes. In that case, this commit, which removed this helpful API, should be reverted: commit c2719503f5e1e6213d716bb078bdad01e28ebcbf Author:

Re: get_random_bytes returns bad randomness before seeding is complete

Further investigations: if the whack-a-mole approach is desirable, perhaps many of those get_random_bytes calls should be converted to get_blocking_random_bytes. In that case, this commit, which removed this helpful API, should be reverted: commit c2719503f5e1e6213d716bb078bdad01e28ebcbf Author:

Re: get_random_bytes returns bad randomness before seeding is complete

(Meanwhile...) In my own code, I'm currently playing with a workaround that looks like this: --- a/src/main.c +++ b/src/main.c +#include +#include +struct rng_initializer { + struct completion done; + struct random_ready_callback cb; +}; +static void

Re: get_random_bytes returns bad randomness before seeding is complete

(Meanwhile...) In my own code, I'm currently playing with a workaround that looks like this: --- a/src/main.c +++ b/src/main.c +#include +#include +struct rng_initializer { + struct completion done; + struct random_ready_callback cb; +}; +static void

get_random_bytes returns bad randomness before seeding is complete

Hi folks, This email is about an issue with get_random_bytes(), the CSPRNG used inside the kernel for generating keys and nonces and whatnot. However, I will begin with an aside: /dev/urandom will return bad randomness before its seeded, rather than blocking, and despite years and years of

get_random_bytes returns bad randomness before seeding is complete

Hi folks, This email is about an issue with get_random_bytes(), the CSPRNG used inside the kernel for generating keys and nonces and whatnot. However, I will begin with an aside: /dev/urandom will return bad randomness before its seeded, rather than blocking, and despite years and years of

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

On Wed, May 24, 2017 at 6:41 PM, Sergei Shtylyov >I've only looked on the last 2 patches. You can add my: > > Reviewed-by: Sergei Shtylyov > > if you want. :-) Will do. For the series, or just for 5/5?

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

On Wed, May 24, 2017 at 6:41 PM, Sergei Shtylyov >I've only looked on the last 2 patches. You can add my: > > Reviewed-by: Sergei Shtylyov > > if you want. :-) Will do. For the series, or just for 5/5?

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

I'm shocked this somehow made it into the commit. I wonder how that happened? Anyway, fixed in my git repo, and will be part of the next series. (Unless DaveM wants to fix it up trivially when/if he merges this v9, which would be faster.) Barring that, does this look good to you? Could I have

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

I'm shocked this somehow made it into the commit. I wonder how that happened? Anyway, fixed in my git repo, and will be part of the next series. (Unless DaveM wants to fix it up trivially when/if he merges this v9, which would be faster.) Barring that, does this look good to you? Could I have

Re: [PATCH net-next v9 0/5] skb_to_sgvec hardening

Hi List, Could somebody do a holistic review of the series, or at least on individual commits that seem fine, and sign off on it, so that this can actually be merged? We're now at v9. I hope we can get this merged now, but if not, I'd like for v10 to finally land these changes. Regards, Jason

Re: [PATCH net-next v9 0/5] skb_to_sgvec hardening

Hi List, Could somebody do a holistic review of the series, or at least on individual commits that seem fine, and sign off on it, so that this can actually be merged? We're now at v9. I hope we can get this merged now, but if not, I'd like for v10 to finally land these changes. Regards, Jason

<    3   4   5   6   7   8   9   10   11   12   >