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

g is seeing if that's true. There are also the AVX512 IFMA instructions to play with! Jason

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

il it is really > usable on CPUs in the market. Actually, similarly here, a 10nm Cannon Lake machine should be arriving at my house this week, which should make for some interesting testing ground for non-throttled zmm, if you'd like to play with it. Jason

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

a potentially useful effort. Regards, Jason size old zinc 0 64 54 16 386 372 32 388 396 48 388 420 64 366 350 80 708 666 96 708 692 112 706 736 128 692 648 144 1036 682 160 1036 708 176 1036 730 192 1016 658 208 1360 684 224 1362 708 240 1360 732 256 644 500 272 990 526 288 988 556 304

Re: .S_shipped unnecessary?

srcdir) vs $(src) in that context? bla bla") that really over complicate things. Jason

.S_shipped unnecessary?

clutter up commits with the .pl _and_ the .S_shipped, what would you think if I just generated the .S each time as an ordinary build artifact. AFAICT, this is fairly usual, and it's hard to see downsides. Hence, why I'm writing this email: are there any downsides to that? Thanks, Jason

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

d to patronize. I don't actually have a bias like that. > But I hope you can understand that all *technical* indicators are that Speck > is > secure enough That's the thing I'm worried about. Jason

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: [RFC 0/2] add integrity and security to TPM2 transactions

capabilities to ensure integrity and to use parameter and response > encryption to ensure confidentiality of the data flowing over the TPM > bus. We have the same issue for TPM1 then right? Jason

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

This would be a big deal and would actually be a noticeable security improvement, instead of a potentially dubious step sidewaysbackish. Bcachefs supports ChaCha20Poly1305, which is pretty neat. From what I've read, performance is acceptable too. http://bcachefs.org/Encryption/ Jason

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

On Thu, Nov 09, 2017 at 09:49:33PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jason, > > On 7 November 2017 at 21:34, Jason Gunthorpe <j...@ziepe.ca> wrote: > > On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote: > > > >>

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

tiple tpm hw in one machine. In case of tpm rng changes I can test > only the lifecycle of tpm rng device. Is that enough? I feel my test > will be limited. Please provide your thoughts on this. That is certainly better than no testing. Jason

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

ey have zero tested-by's. Hopefully PrasannaKumar can test both patches. Jason

[PATCH v2] tpm: Move Linux RNG connection to hwrng

Muralidharan <prasannatsmku...@gmail.com> Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> --- drivers/char/hw_random/Kconfig | 13 --- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_random/tpm-rng.c | 50 drivers/char

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

ay that instead a struct tpm_chip > instance is given and NULL means the default chip. In addition, this > commit refines the documentation to be up to date with the > implementation. > > Suggested-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> (@chip_num -> &g

Re: [PATCH v3] tpm: use struct tpm_chip for tpm_chip_find_get()

en you make, and here you found a bug, so very good. Got to start someplace. Jason

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

idr_alloc(). We should never use index inside the kernel. > Address is a reusable identifier in one boot cycle. It is invalid to pass in a chip for which the caller does not hold a kref, so address is the safest argument. Jason

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Wed, Oct 25, 2017 at 10:00:30PM +0200, Jarkko Sakkinen wrote: > A minor tidbit: could the tpm_ prefix removed from those fields? Yes, in v2 I will send v2 when you land your rework patch as this will depend on it. Jason

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

(!tpm_try_get_ops(chip)) res = chip; } mutex_unlock(_lock); return res; } Jason

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

DOM_TPM be used instead? That way an if > > condition can be avoided. > > Nope. There is no reason to avoid the if-condition. Compiler will take > care of it. IS_ENABLED() macro is available just for the purpose Jason > is using it. > > > > + char tpm_hwrng_name[

Re: [PATCH v2] tpm: use struct tpm_chip for tpm_chip_find_get()

ay that instead a struct tpm_chip > instance is given and NULL means the default chip. In addition, this > commit refines the documentation to be up to date with the > implementation. > > Suggested-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> (@chip_num -> &g

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

_TPM be used instead? That way an if > condition can be avoided. Generally speaking IS_ENABLED is prefered over #ifdef as it reduces the set of compilation combinations. Jason

Re: [PATCH] tpm: Move Linux RNG connection to hwrng

On Tue, Oct 24, 2017 at 12:42:35PM -0600, Jason Gunthorpe wrote: > This is compile tested only. 0day says the kconfig has a problem when randomized, here is the fix I will roll into a v2 in a few days: diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig index a95725fa777

Re: [PATCH] tpm: remove chip_num parameter from in-kernel API

g an 'int chip_num' to tpm_chip_find_get, flow the 'struct tpm_chip *' directly. This gets us much closer to the desired API with about the same amount of churn as this patch has. Jason

[PATCH] tpm: Move Linux RNG connection to hwrng

Muralidharan <prasannatsmku...@gmail.com> Signed-off-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> Reviewed-by: Jason Gunthorpe <jguntho...@obsidianresearch.com> --- drivers/char/hw_random/Kconfig | 13 --- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_ran

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

eral rule in the kernel for things like this it to use pointers, not ids, and certainly not string ids. For that patch it could just use container_of to get the chip.. Jason

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

'add_early_randomness'.. We can certainly provide a TPM interface to hwrng, it seems reasonable. Excep that we already have a user api in /dev/tpm to access the tpm RNG, is the duplication a problem? Jason

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

On Tue, Oct 24, 2017 at 09:37:33PM +0530, PrasannaKumar Muralidharan wrote: > Hi Jason, > > On 24 October 2017 at 21:25, Jason Gunthorpe > <jguntho...@obsidianresearch.com> wrote: > > On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote: > >

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

h isn't safe at all. You need to store a kref to th chip in the hwrng, not parse a string. Jason

Re: [tpmdd-devel] [PATCH] tpm: remove chip_num parameter from in-kernel API

(tpm2) ret = tpm_unseal_trusted(tpm, payload, options); [..] tpm_put_chip(tpm); As hot plug could alter the 'tpm' between the two tpm calls. Jason

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 0/3] crypto: marvell - Remove the old CESA driver

ho originally requested this transitioning time, Acked-by: Jason Cooper <ja...@lakedaemon.net> For the series. thx, Jason.

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

going to roll Kees' suggestion into a PATCH and send it to you. You can decide if you want to apply it. I'll be satisfied with whatever you choose and will follow your lead. Jason

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

make this change and submit a new patch to Ted. Jason

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

ges. So, I still think this current strategy is a good one, of default y, but depends on DEBUG_KERNEL. Regards, Jason

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

now to wait and try again? The process just remains in interruptible (kill-able) sleep until there is enough entropy, so the process doesn't need to do anything. If the waiting is interrupted by a signal, it returns -ESYSRESTART, which follows the usual semantics of restartable syscalls. Jason

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

s exactly what I intended it to do. The reason is that I'd like to avoid a lock imbalance, which could happen if the read is inlined. Jason

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

and give your Signed-off-by if it looks good? Jason

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

tivel, information about how to kick off some kind of automated > test suite ala xfstests for file systems. Only very basic testing from my end. I'm thus adding the iSCSI list to see if they'll have a look (patch reattached). Jason From 1adecf785526a2a96104767807140b9e1a9e2a27 Mon Sep 17 00:00

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

u confirm with certainty whether or not all calls to get_random_bytes() in the bluetooth directory are *necessarily* going to come after a call to hci_power_on()? Jason

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

  1   2   3   4   >