Re: [PATCH 0/6] crypto: x86/chacha20 - SIMD performance improvements

Hi Martin, On Tue, Nov 20, 2018 at 5:29 PM Martin Willi wrote: > Thanks for the offer, no need at this time. But I certainly would > welcome if you could do some (Wireguard) benching with that code to see > if it works for you. I certainly will test it in a few different network circumstances,

Re: [PATCH 0/6] crypto: x86/chacha20 - SIMD performance improvements

Hi Martin, On Mon, Nov 19, 2018 at 8:52 AM Martin Willi wrote: > > Adding AVX-512VL support is relatively simple. I have a patchset mostly > ready that is more than competitive with the code from Zinc. I'll clean > that up and do more testing before posting it later this week. Terrific.

Re: [PATCH 0/6] crypto: x86/chacha20 - SIMD performance improvements

Hi Martin, This is nice work, and given that it's quite clean -- and that it's usually hard to screw up chacha in subtle ways when test vectors pass (unlike, say, poly1305 or curve25519), I'd be inclined to roll with your implementation if it can eventually become competitive with Andy

Re: .S_shipped unnecessary?

Hey Ard, On Fri, Nov 9, 2018 at 12:42 AM Ard Biesheuvel wrote: > Wonderful! Any problems doing that for x86_64 ? The x86_64 is still a WIP, but hopefully we'll succeed. > I agree 100%. When I added this the first time, it was at the request > of the ARM maintainer, who was reluctant to rely on

.S_shipped unnecessary?

Hi Ard, Eric, and others, As promised, the next Zinc patchset will have less generated code! After a bit of work with Andy and Samuel, I'll be bundling the perlasm. One thing I'm wondering about, though, is the wisdom behind the current .S_shipped pattern. Usually the _shipped is for big

Re: [PATCH net-next v6 07/23] zinc: ChaCha20 ARM and ARM64 implementations

On Wed, Sep 26, 2018 at 5:42 PM Ard Biesheuvel wrote: > > On Wed, 26 Sep 2018 at 16:02, Ard Biesheuvel > wrote: > Actually, looking at the code again, the abstraction does appear to be > fine, it is just the chacha20 code that does not make use of it. So what you have in mind is something like

Re: [PATCH v2 0/5] crypto: Speck support

Hi Eric, On Tue, Apr 24, 2018 at 8:16 PM, Eric Biggers wrote: > So, what do you propose replacing it with? Something more cryptographically justifiable. > outside crypto review, vs. the many cryptanalysis papers on Speck. (In that > respect the controversy about Speck has

Re: [PATCH v2 0/5] crypto: Speck support

Can we please not Speck? It was just rejected by the ISO/IEC. https://twitter.com/TomerAshur/status/988659711091228673

[PATCH] crypto: remove Speck

This NSA-designed cipher was rejected for inclusion in international standards by ISO/IEC. Before anyone actually starts using it by accident, let's just not ship it at all. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- arch/arm/crypto/Kconfig |6 - arch/arm/

Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

Hi Eric, Nice to see more use of ChaCha20. However... Can we skip over the "sort of worse than XTS, but not having _real_ authentication sucks anyway in either case, so whatever" and move directly to, "linux finally supports authenticated encryption for disk encryption!"? This would be a big

Re: [PATCH 1/2] random: always call random ready function

Good tips, thanks. I'll wait for more comments before resubmitting v2, but in-progress changes live here: https://git.zx2c4.com/linux-dev/log/?h=jd/cleaner-add-random-ready

[PATCH 2/2] crypto/drbg: account for no longer returning -EALREADY

We now structure things in a way that assumes the seeding function is always eventually called. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- crypto/drbg.c | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c

Re: [PATCH 1/2] random: always call random ready function

These are mostly untested, but I wanted to spec it out for a taste of what it looks like.

[PATCH 1/2] random: always call random ready function

As this interface becomes more heavily used, it will be painful for callers to always need to check for -EALREADY. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- drivers/char/random.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/d

Re: [PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

Hi Herbert, Can we get this reviewed for rc5 please? Thanks, Jason

Re: [PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

s/objdump/objtool/g obviously.

[PATCH] chacha20-ssse3/avx2: satisfy stack validation 2.0

This fixes things up to use code similar to gcc's DRAP register, so that objdump remains happy. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Fixes: baa41469a7b9 ("objtool: Implement stack validation 2.0") --- arch/x86/crypto/chacha20-avx2-x86_64.S | 4 ++-- arch/x86/crypto/chacha2

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

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/crypto/rng.c index 5e8469244960..b4a618668161 100644 --- a/crypto/rng.c +++ b/crypto/rng.c @@ -43,12 +43,14 @@ int crypto_rng_reset(struc

Re: [kernel-hardening] [PATCH] random: warn when kernel uses unseeded randomness

l issue with that architecture > or subarchitecture. To see all uses of unseeded randomness, > developers can enable CONFIG_WARN_ALL_UNSEEDED_RANDOM. Seems fine to me. Acked-by: Jason A. Donenfeld <ja...@zx2c4.com> Jason

[PATCH] 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> Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- Hi Ted, This patch is meant to replace d06bfd1989fe97623b32d6df4ffa6e4338c99dc8, which is currently in y

Re: [PATCH] random: silence compiler warnings and fix race

On Wed, Jun 21, 2017 at 1:38 AM, Theodore Ts'o wrote: > The punch was in response to this statement, which I personally found > fairly infuriating: > >>> I more or less agree with you that we should just turn this on for all >>> users and they'll just have to live with the spam and

Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 8:14 PM, Kees Cook wrote: > How about doing this: > >default DEBUG_KERNEL > > Most distro kernel select DEBUG_KERNEL because it unhides a bunch of > other useful configs. Since it doesn't strictly _depend_ on > DEBUG_KERNEL, I think it's probably

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 11:36 AM, Theodore Ts'o wrote: >> But I think there's another camp that would mutiny in the face of this >> kind of hubris. > > Blocking the boot for hours and hours until we have enough entropy to > initialize the CRNG is ***not*** an acceptable way of

Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 10:33 AM, Jeffrey Walton wrote: > I think it is a bad idea to suppress all messages from a security > engineering point of view. > > Many folks don't run debug kernels. Most of the users who want or need > to know of the issues won't realize its

Re: [PATCH] random: silence compiler warnings and fix race

Hey Ted, On Tue, Jun 20, 2017 at 02:03:44AM -0400, Theodore Ts'o wrote: > I actually had set up an earlier version of your patch for on Saturday > while I was in Beijing. (Like Linus, I'm attending the LinuxCon China > conference Monday and Tuesday.) I had even created the signed tag, > I've

Re: [PATCH] random: silence compiler warnings and fix race

Hello Ted, With rc6 already released and rc7 coming up, I'd really appreciate you stepping in here and either ACKing the above commit, or giving your two cents about it in case I need to roll something different. Thanks, Jason On Thu, Jun 15, 2017 at 12:45 AM, Jason A. Donenfeld <ja...@zx

Re: [PATCH] random: silence compiler warnings and fix race

On Mon, Jun 19, 2017 at 9:45 AM, Sebastian Andrzej Siewior wrote: > ehm. You sure? I simply delayed the lock-dropping _after_ the state > variable was been modified. So it was basically what your patch did > except it was unlocked later… Yes, I'm sure. You moved the call

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 7:55 PM, Stephan Müller wrote: > But you bring up an interesting point: if it is true you say that it is hard > for people to use differnent types of APIs regarding entropy and random > numbers right (which I would concur with), and considering that

Re: [kernel-hardening] Re: [PATCH v4 13/13] random: warn when kernel uses unseeded randomness

On Sun, Jun 18, 2017 at 5:46 PM, Theodore Ts'o wrote: > You are effectively proposing that there ought to be a middle range of > security between prandom_32, get_random_u32/get_random_u64 and > get_random_bytes(). I think that's going to lead to all sorts of > complexity and bugs

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

Hi Lee, On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan wrote: > It seems like what you are doing is basically "good", i.e. if there is > not enough random data, don't use it. But what happens in that case? The > authentication fails? How does the user know to wait and try again?

Re: [PATCH] random: silence compiler warnings and fix race

On Fri, Jun 16, 2017 at 4:35 PM, Sebastian Andrzej Siewior wrote: > I wouldn't just push the lock one up as is but move that write part to > crng_init to remain within the locked section. Like that: We can't quite do that, because invalidate_batched_entropy() needs to be

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

On Fri, Jun 16, 2017 at 10:31 AM, Sebastian Andrzej Siewior wrote: > am talking about. Again: I actually figured that out myself after sending the initial email, so then I wrote a follow-up patch which I attached to this thread. You should have received it. Can you take

[PATCH] random: silence compiler warnings and fix race

be called in opposite order. Moving the call to invalidate_batched_entropy to outside the lock rectifies this issue. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> --- Ted -- the first part of this is the fixup patch we discussed earlier. Then I added on top a fix for a potentially relate

Re: [PATCH v5 01/13] random: invalidate batched entropy after crng init

There's a potential race that I fixed in my v5 of that patch set, but Ted only took v4, and for whatever reason has been to busy to submit the additional patch I already posted showing the diff between v4 Hopefully he actually gets around to it and sends this for the next rc. Here it is:

[PATCH] rsa-pkcs1pad: use constant time memory comparison for MACs

Otherwise, we enable all sorts of forgeries via timing attack. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Suggested-by: Stephan Müller <smuel...@chronox.de> Cc: sta...@vger.kernel.org Cc: Herbert Xu <herb...@gondor.apana.org.au> Cc: linux-crypto@vger.kernel.org --- cry

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

On Thu, Jun 8, 2017 at 7:05 PM, Marcel Holtmann wrote: > on a powered down controller, you can not do any crypto. SMP is only during a > connection and the RPAs are only generated when needed. So yes, doing this > once in hci_power_on is plenty. However we might want to

Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

t'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 condition. Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: "Nicholas A. Bellinger" <n...@linux-iscsi.org

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

Hello Marcel, On Thu, Jun 8, 2017 at 7:04 AM, Marcel Holtmann wrote: > yes, there are plenty of commands needed before a controller becomes usable. That doesn't clearly address with precision what Ted was wondering. Specifically, the inquiry is: can you confirm with

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

On Thu, Jun 8, 2017 at 10:19 AM, Theodore Ts'o wrote: > At the very least we probably should do a logical "uniq" on the output > (e.g., if we have complained about the previous callsite, don't whinge > about it again). That seems okay to me.

Re: [PATCH v4 04/13] security/keys: ensure RNG is seeded before use

On Thu, Jun 8, 2017 at 2:50 AM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o <ty...@mit.edu> wrote: >> I'm guessing you changed key_alloc_serial() to return an int back when >> you were thinking that you might use get

Re: [PATCH v4 01/13] random: invalidate batched entropy after crng init

On Thu, Jun 8, 2017 at 1:58 AM, Theodore Ts'o wrote: > Thanks, applied. This will be on the for_stable that I will be > sending to Linus sometime during 4.12-rcX. I think you might have just missed the kbuild test robot complaining about an incorrect compiler warning, when using

Re: [PATCH v4 04/13] security/keys: ensure RNG is seeded before use

On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o wrote: > I'm guessing you changed key_alloc_serial() to return an int back when > you were thinking that you might use get_random_bytes_wait(), which > could return -ERESTARTSYS. > > Now that you're not doing this, but using

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

On Thu, Jun 8, 2017 at 2:41 AM, Theodore Ts'o wrote: > The use in keys/big_key is _being_ removed, so this commit is > dependent on that commit landing, correct? (Order matters, because > otherwise we don't want to potentially screw up doing a kernel bisect > and causing their

Re: [kernel-hardening] [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random

On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o wrote: > There's a bigger problem here, which is that cifs_lock_secret is a > 32-bit value which is being used to obscure flock->fl_owner before it > is sent across the wire. But flock->fl_owner is a pointer to the > struct file *, so

Re: [kernel-hardening] [PATCH v4 08/13] cifs: use get_random_u32 for 32-bit lock random

On Thu, Jun 8, 2017 at 2:25 AM, Theodore Ts'o wrote: > There's a bigger problem here, which is that cifs_lock_secret is a > 32-bit value which is being used to obscure flock->fl_owner before it > is sent across the wire. But flock->fl_owner is a pointer to the > struct file *, so

[PATCH v5 02/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 v5 04/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 v5 00/13] Unseeded In-Kernel Randomness Fixes

://www.openwall.com/lists/kernel-hardening/2017/06/02/2 Changes v4->v5: - Old versions of gcc warned on an uninitialized variable, so set this to silence warning. Jason A. Donenfeld (13): random: invalidate batched entropy after crng init random: add synchronous API for the urandom pool ran

[PATCH v5 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 v5 05/13] crypto/rng: ensure that the RNG is ready before using

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/crypto/rng.c index f46dac5288b9..e042437e64b4 100644 --- a/crypto/rng.c +++ b/crypto/rng.c @@ -48,12 +48,14 @@ int crypto_rng_reset(struc

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

series from January, this patch, and then the ones that come after, I think there's a relevant amount of code in here to add my name to the top.) Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/char/r

[PATCH v5 01/13] random: invalidate batched entropy after crng init

series from January, this patch, and then the ones that come after, I think there's a relevant amount of code in here to add my name to the top.) Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/char/r

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

://www.openwall.com/lists/kernel-hardening/2017/06/02/2 Changes v4->v5: - Old versions of gcc warned on an uninitialized variable, so set this to silence warning. Jason A. Donenfeld (13): random: invalidate batched entropy after crng init random: add synchronous API for the urandom pool ran

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

Strange, not all compilers do this warning. Fixing with: diff --git a/drivers/char/random.c b/drivers/char/random.c index 12758db..5252690 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -2061,8 +2061,8 @@ static DEFINE_PER_CPU(struct batched_entropy, batched_entropy_u64); u64

Re: [PATCH v4 00/13] Unseeded In-Kernel Randomness Fixes

Hi Ted, Could I get your Signed-off-by on this patchset, so that somebody can add it to their tree? Thanks, Jason

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

On Tue, Jun 6, 2017 at 7:57 PM, Stephan Müller wrote: > Finally, I am very surprised that I get hardly any answers on patches to > random.c let alone that any changes to random.c will be applied at all. FWIW, this is my biggest concern too. You seem willing to work on this

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

series from January, this patch, and then the ones that come after, I think there's a relevant amount of code in here to add my name to the top.) Signed-off-by: Jason A. Donenfeld <ja...@zx2c4.com> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org> --- drivers/char/r

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

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/crypto/rng.c index f46dac5288b9..e042437e64b4 100644 --- a/crypto/rng.c +++ b/crypto/rng.c @@ -48,12 +48,14 @@ int crypto_rng_reset(struc

[PATCH v4 04/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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 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 v4 02/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 v4 00/13] Unseeded In-Kernel Randomness Fixes

ble - Operation ordering on batched entropy invalidation - Separate out big_key into its own patch to the keys mailing list - General cleanups Jason A. Donenfeld (13): random: invalidate batched entropy after crng init random: add synchronous API for the urandom pool random: add get_random_{by

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

On Tue, Jun 6, 2017 at 7:26 PM, Eric Biggers wrote: > I agree that the use of ECB mode in big_key is broken, and thanks for trying > to > fix it! I think using GCM is good, but please leave a very conspicuous > comment > where the nonce is being set to 0, noting that it's

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

On Tue, Jun 6, 2017 at 7:03 PM, Theodore Ts'o wrote: > So it's not clear what you mean by Stephan's work. I just meant that there's a guy out there who seems really motivated to work on this stuff in detail, but hasn't seen too much love, AFAIK. I'm sure there's an interesting

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

Hey again Eric, One thing led to another and I wound up just rewriting all the crypto in big_keys.c. I'll include this for v4: https://git.zx2c4.com/linux-dev/commit/?h=jd/rng-blocker=886ff283b9808aecb14aa8e397da8496a9635aed Not only was the use of crypto/rng inappropriate, but the decision to

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: [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 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 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 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,

[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 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 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 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 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 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 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 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 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 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 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 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 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 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

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

  1   2   3   >