[PATCH -v2] random: mix rdrand with entropy sent in from userspace

ream. And if RDRAND is in fact an honest DRNG, it will immeasurably improve on what the Jitter entropy daemon might produce. This also provides some protection against someone who is able to read or set the entropy seed file. Signed-off-by: Theodore Ts'o Cc: sta...@vger.kernel.org Cc: Arnd Bergmann

[PATCH] random: mix rdrand with entropy sent in from userspace

ream. And if RDRAND is in fact an honest DRNG, it will immeasurably improve on what the Jitter entropy daemon might produce. This also provides some protection against someone who is able to read or set the entropy seed file. Signed-off-by: Theodore Ts'o Cc: sta...@vger.kernel.org --- driver

[PATCH 1/5] random: fix crng_ready() test

. The crng_ready() function should only return true once we are in the last state. Reported-by: Jann Horn <ja...@google.com> Fixes: e192be9d9a30 ("random: replace non-blocking pool...") Cc: sta...@kernel.org # 4.8+ Signed-off-by: Theodore Ts'o <ty...@mit.edu> Reviewed-by: Jann

[PATCH 2/5] random: use a different mixing algorithm for add_device_randomness()

s") Cc: sta...@kernel.org # 4.13+ Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 55 +++ 1 file changed, 51 insertions(+), 4 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index c8ec1e70abd

[PATCH 4/5] random: crng_reseed() should lock the crng instance that it is modifying

Reported-by: Jann Horn <ja...@google.com> Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...") Cc: sta...@kernel.org # 4.8+ Signed-off-by: Theodore Ts'o <ty...@mit.edu> Reviewed-by: Jann Horn <ja...@google.com> --- drivers/char/random.c | 4 ++--

[PATCH 3/5] random: set up the NUMA crng instances after the CRNG is fully initialized

a lot of legacy code out there. Reported-by: Jann Horn <ja...@google.com> Fixes: 1e7f583af67b ("random: make /dev/urandom scalable for silly...") Cc: sta...@kernel.org # 4.8+ Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 46 +++

[PATCH 5/5] random: add new ioctl RNDRESEEDCRNG

Add a new ioctl which forces the the crng to be reseeded. Signed-off-by: Theodore Ts'o <ty...@mit.edu> Cc: sta...@kernel.org --- drivers/char/random.c | 13 - include/uapi/linux/random.h | 3 +++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/driver

Re: random.c: LFSR polynomials are not irreducible/primitive

On Tue, Aug 15, 2017 at 10:45:17AM +0200, Stephan Mueller wrote: > Am Dienstag, 15. August 2017, 00:21:05 CEST schrieb Theodore Ts'o: > > Hi Theodore, > > > Have you looked at section 3.1.1 of the above cited paper? > > > > http://eprint.iacr.org/2012/25

Re: random.c: LFSR polynomials are not irreducible/primitive

On Mon, Aug 14, 2017 at 10:20:18AM +0200, Stephan Mueller wrote: > Hi Ted, > > drivers/char/random.c contains the following comment: > > """ > * Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and > * Videau in their paper, "The Linux Pseudorandom Number Generator > *

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Sun, Jul 23, 2017 at 02:05:38PM -0400, Sandy Harris wrote: > Sandy Harris wrote: > > > The biggest problem with random(4) is that you cannot generate good > > output without a good seed & just after boot, ... > > > > The only really good solution I know of is to find a

Re: Poor RNG performance on Ryzen

On Fri, Jul 21, 2017 at 04:55:12PM +0200, Oliver Mangold wrote: > On 21.07.2017 16:47, Theodore Ts'o wrote: > > On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote: > > > Better, but obviously there is still much room for improvement by reducing > > > th

Re: Poor RNG performance on Ryzen

On Fri, Jul 21, 2017 at 01:39:13PM +0200, Oliver Mangold wrote: > Better, but obviously there is still much room for improvement by reducing > the number of calls to RDRAND. Hmm, is there some way we can easily tell we are running on Ryzen? Or do we believe this is going to be true for all AMD

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Thu, Jul 20, 2017 at 09:00:02PM +0200, Stephan Müller wrote: > I concur with your rationale where de-facto the correlation is effect is > diminished and eliminated with the fast_pool and the minimal entropy > estimation of interrupts. > > But it does not address my concern. Maybe I was not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote: > In the email [1] I have expressed the core concerns I see -- none of them > address the need to keep the Jitter RNG as one noise source. To address > those, > a very deep dive into random.c needs to be made. That's simply not

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 09:00:10PM -0400, Sandy Harris wrote: > The only really good solution I know of is to find a way to provide a > chunk of randomness early in the boot process. John Denker has a good > discussion of doing this by modifying the kernel image & Ted talks of > doing it via the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 04:37:11PM +0200, Stephan Müller wrote: > > > > > I have stated the core concerns I have with random.c in [1]. To remedy > > > these core concerns, major changes to random.c are needed. With the past > > > experience, I would doubt that I get the changes into random.c. > >

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

On Wed, Jul 05, 2017 at 09:16:09AM -0400, Paul Koning wrote: > > In the implementations I know, /dev/random and /dev/urandom are the > same driver, the only difference is that when you read from > /dev/random there's a check for the current entropy level. It's in the same driver but /dev/random

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

On Wed, Jul 05, 2017 at 09:03:43AM +0200, Ulrich Windl wrote: > > Note, during the development of my /dev/random implementation, I added the > > getrandom-like blocking behavior to /dev/urandom (which is the equivalent to > > Jason's patch except that it applies to user space). The boot process

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

ch replaces the current topmost patch on the random.git tree: >From 25b683ee9bd5536807f813efbd19809333461f89 Mon Sep 17 00:00:00 2001 From: Theodore Ts'o <ty...@mit.edu> Date: Thu, 8 Jun 2017 04:16:59 -0400 Subject: [PATCH] random: suppress spammy warnings about unseeded randomness Unfortunately, on som

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

On Tue, Jun 20, 2017 at 11:49:07AM +0200, Jason A. Donenfeld wrote: > Uh, talk about a totally unnecessary punch... In case my last email > wasn't clear, I fully recognize that `default y` is a tad too extreme, > which is why from one of the earliest revisions in this series, I > moved directly to

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

On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: > > Suppressing all messages for all configurations cast a wider net than > > necessary. Configurations that could potentially be detected and fixed > > likely will go unnoticed. If the problem is not brought to light, then > > it

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

On Mon, Jun 19, 2017 at 10:57:18PM +0200, Jason A. Donenfeld wrote: > > 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. I actually had set

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

On Thu, Jun 15, 2017 at 01:59:43PM +0200, Stephan Müller wrote: > I would think that the issue regarding the logging is relevant for > cryptographic use cases or use cases requiring strong random numbers only. > Only those use cases should be fixed eventually to wait for a fully seeded > DRNG.

Re: Crypto Fixes for 4.12

On Thu, Jun 15, 2017 at 11:01:18AM -0400, David Miller wrote: > As a side note, ext4 does something similar with a private > implementation, but it doesn't use something the evaluates to an > alloca. Instead it uses a fixed 4-byte size for the shash context > value in the on-stack declaration.

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

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). - Ted commit 9d9035bc6d7871a73d7f9aada4e63cb190874a68 Author: Theodore Ts'o <ty...@mit.edu> Date:

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

On Tue, Jun 06, 2017 at 07:48:03PM +0200, Jason A. Donenfeld wrote: > This protocol uses lots of complex cryptography that relies on securely > generated random numbers. Thus, it's important that the RNG is actually > seeded before use. Fortuantely, it appears we're always operating in > process

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

On Tue, Jun 06, 2017 at 07:48:02PM +0200, Jason A. Donenfeld wrote: > Using get_random_int here is faster, more fitting of the use case, and > just as cryptographically secure. It also has the benefit of providing > better randomness at early boot, which is when many of these structures > are

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

On Tue, Jun 06, 2017 at 07:48:01PM +0200, Jason A. Donenfeld wrote: > 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

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

On Tue, Jun 06, 2017 at 07:48:00PM +0200, Jason A. Donenfeld wrote: > 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:

Re: [kernel-hardening] [PATCH v4 07/13] ceph: ensure RNG is seeded before using

On Tue, Jun 06, 2017 at 07:47:58PM +0200, Jason A. Donenfeld wrote: > Ceph uses the RNG for various nonce generations, and it shouldn't accept > using bad randomness. So, we wait for the RNG to be properly seeded. We > do this by calling wait_for_random_bytes() in a function that is > certainly

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

On Tue, Jun 06, 2017 at 07:47:57PM +0200, Jason A. Donenfeld wrote: > It's not safe to use weak random data here, especially for the challenge > response randomness. Since we're always in process context, it's safe to > simply wait until we have enough randomness to carry out the > authentication

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

On Tue, Jun 06, 2017 at 07:47:56PM +0200, Jason A. Donenfeld wrote: > Otherwise, we might be seeding the RNG using bad randomness, which is > dangerous. The one use of this function from within the kernel -- not > from userspace -- is being removed (keys/big_key), so that call site > isn't

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

On Tue, Jun 06, 2017 at 07:47:55PM +0200, Jason A. Donenfeld wrote: > -static inline void key_alloc_serial(struct key *key) > +static inline int key_alloc_serial(struct key *key) > @@ -170,7 +168,7 @@ static inline void key_alloc_serial(struct key *key) > rb_insert_color(>serial_node,

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

On Tue, Jun 06, 2017 at 07:47:59PM +0200, Jason A. Donenfeld wrote: > 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. > >

Re: [kernel-hardening] [PATCH v4 03/13] random: add get_random_{bytes,u32,u64,int,long,once}_wait family

On Tue, Jun 06, 2017 at 07:47:54PM +0200, Jason A. Donenfeld wrote: > 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 Thanks, applied to the dev

Re: [PATCH v4 02/13] random: add synchronous API for the urandom pool

On Tue, Jun 06, 2017 at 07:47:53PM +0200, Jason A. Donenfeld wrote: > 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

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

On Tue, Jun 06, 2017 at 07:47:52PM +0200, Jason A. Donenfeld wrote: > It's possible that get_random_{u32,u64} is used before the crng has > initialized, in which case, its output might not be cryptographically > secure. For this problem, directly, this patch set is introducing the > *_wait variety

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

On Wed, Jun 07, 2017 at 07:00:17AM +0200, Stephan Müller wrote: > > On that same idea, one could add an early_initramfs handler for entropy > > data. > > Any data that comes from outside during the boot process, be it some NVRAM > location, the /var/lib...seed file for /dev/random or other

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

On Tue, Jun 06, 2017 at 07:19:10PM -0300, Henrique de Moraes Holschuh wrote: > On that same idea, one could add an early_initramfs handler for entropy > data. > > One could also ensure the kernel command line is used to feed some > entropy for the CRNG init (for all I know, this is already being

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

On Tue, Jun 06, 2017 at 02:34:43PM +0200, Jason A. Donenfeld wrote: > > Yes, I agree whole-heartedly. A lot of people have proposals for > fixing the direct idea of entropy gathering, but for whatever reason, > Ted hasn't merged stuff. I think Stephan (CCd) rewrote big critical > sections of the

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

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

Re: get_random_bytes returns bad randomness before seeding is complete

On Sat, Jun 03, 2017 at 01:58:25AM +0200, Jason A. Donenfeld wrote: > Hi Ted, > > Based on the tone of your last email, before I respond to your > individual points May I gently point out that *your* tone that started this whole thread has been pretty terrible? Quoting your your first

Re: get_random_bytes returns bad randomness before seeding is complete

On Fri, Jun 02, 2017 at 07:44:04PM +0200, Jason A. Donenfeld wrote: > On Fri, Jun 2, 2017 at 7:26 PM, Theodore Ts'o <ty...@mit.edu> wrote: > > I tried making /dev/urandom block. > > So if you're a security focused individual who is kvetching > > And if we're bre

Re: get_random_bytes returns bad randomness before seeding is complete

heir dmesg and > write emails like this one to the list. The #ifdef and the printk was there from the very beginning. commit 392a546dc8368d1745f9891ef3f8f7c380de8650 Author: Theodore Ts'o <ty...@mit.edu> Date: Sun Nov 3 18:24:08 2013 -0500 random: add debugging code to detect early u

Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()

On Thu, Feb 09, 2017 at 01:13:22AM -0700, Alden Tondettar wrote: > And using: > > $ qemu-system-x86_64 --version > QEMU emulator version 2.1.2 (Debian 1:2.1+dfsg-12+deb8u6), Copyright (c) > 2003-2008 Fabrice Bellard > $ qemu-system-x86_64 -nographic -enable-kvm -m 1024M -kernel bzImage -append

Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()

OK, I figured out what is going on with your test results. If you use qemu-system-x86_64 **without** --enable-kvm, then on both the Debian Jessie version of qemu as well as the Debian Stretch version of qemu, crng_fast_load() will be called _twice_ before crng_initialize has a chance to be

Re: [PATCH] random: Don't overwrite CRNG state in crng_initialize()

On Wed, Feb 08, 2017 at 08:31:26PM -0700, Alden Tondettar wrote: > The new non-blocking system introduced in commit e192be9d9a30 ("random: > replace non-blocking pool with a Chacha20-based CRNG") can under > some circumstances report itself initialized while it still contains > dangerously little

Re: [PATCH 7/8] random: remove noop function call to xfer_secondary_pool

On Tue, Dec 27, 2016 at 11:41:46PM +0100, Stephan Müller wrote: > Since the introduction of the ChaCha20 DRNG, extract_entropy is only > invoked with the input_pool. For this entropy pool, xfer_secondary_pool > is a no-op and can therefore be safely removed. > > Signed-off-by: Stephan Mueller

Re: [PATCH 4/8] random: remove unused branch in hot code path

On Tue, Dec 27, 2016 at 11:40:23PM +0100, Stephan Müller wrote: > The variable ip is defined to be a __u64 which is always 8 bytes on any > architecture. Thus, the check for sizeof(ip) > 4 will always be true. > > As the check happens in a hot code path, remove the branch. The fact that it's a

Re: [PATCH 3/8] random: trigger random_ready callback upon crng_init == 1

On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote: > The random_ready callback mechanism is intended to replicate the > getrandom system call behavior to in-kernel users. As the getrandom > system call unblocks with crng_init == 1, trigger the random_ready > wakeup call at the same

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:08:37PM +0100, Hannes Frederic Sowa wrote: > I wasn't concerned about performance but more about DoS resilience. I > wonder how safe half md4 actually is in terms of allowing users to > generate long hash chains in the filesystem (in terms of length > extension attacks

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 05:16:47PM +0100, Jason A. Donenfeld wrote: > Could you offer a bit of advice on how to manage dependencies between > patchsets during merge windows? I'm a bit new to the process. > > Specifically, we how have 4 parts: > 1. add siphash, and use it for some networking code.

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 07:03:29AM +0100, Jason A. Donenfeld wrote: > I find this compelling. We'll have one csprng for both > get_random_int/long and for /dev/urandom, and we'll be able to update > that silly warning on the comment of get_random_int/long to read > "gives output of either rdrand

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > wrote: > > following up on what appears to be a random subject: ;) > > > > IIRC, ext4 code by default still uses half_md4 for hashing of

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > Funny -- while you guys were sending this back & forth, I was writing > my reply to Andy which essentially arrives at the same conclusion. > Given that we're all arriving to the same thing, and that Ted shot in > this

Re: HalfSipHash Acceptable Usage

On Wed, Dec 21, 2016 at 01:37:51PM -0500, George Spelvin wrote: > SipHash annihilates the competition on 64-bit superscalar hardware. > SipHash dominates the field on 64-bit in-order hardware. > SipHash wins easily on 32-bit hardware *with enough registers*. > On register-starved 32-bit machines,

Re: HalfSipHash Acceptable Usage

On Mon, Dec 19, 2016 at 06:32:44PM +0100, Jason A. Donenfeld wrote: > 1) Anything that requires actual long-term security will use > SipHash2-4, with the 64-bit output and the 128-bit key. This includes > things like TCP sequence numbers. This seems pretty uncontroversial to > me. Seem okay to

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 09:15:03PM -0500, George Spelvin wrote: > >> - Ted, Andy Lutorminski and I will try to figure out a construction of > >> get_random_long() that we all like. We don't have to find the most optimal solution right away; we can approach this incrementally, after all. So

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016 at 03:17:39PM -0500, George Spelvin wrote: > > That's a nice analysis. Might one conclude from that that hsiphash is > > not useful for our purposes? Or does it still remain useful for > > network facing code? > > I think for attacks where the threat is a DoS, it's usable.

Re: [PATCH 4/3] random: use siphash24 instead of md5 for get_random_int/long

On Wed, Dec 14, 2016 at 04:10:37AM +0100, Jason A. Donenfeld wrote: > This duplicates the current algorithm for get_random_int/long, but uses > siphash24 instead. This comes with several benefits. It's certainly > faster and more cryptographically secure than MD5. This patch also > hashes the pid,

Re: [PATCH 2/2] fscrypto: don't use on-stack buffer for key derivation

On Thu, Nov 03, 2016 at 03:03:02PM -0700, Eric Biggers wrote: > With the new (in 4.9) option to use a virtually-mapped stack > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for > the scatterlist crypto API because they may not be directly mappable to > struct page.

Re: [PATCH 1/2] fscrypto: don't use on-stack buffer for filename encryption

On Thu, Nov 03, 2016 at 03:03:01PM -0700, Eric Biggers wrote: > With the new (in 4.9) option to use a virtually-mapped stack > (CONFIG_VMAP_STACK), stack buffers cannot be used as input/output for > the scatterlist crypto API because they may not be directly mappable to > struct page. For short

Re: [PATCH 6/7] random: make /dev/urandom scalable for silly userspace programs

On Sun, Aug 21, 2016 at 12:53:15PM +0300, Jan Varho wrote: > On Mon, Jun 13, 2016 at 6:48 PM, Theodore Ts'o <ty...@mit.edu> wrote: > > +static inline void maybe_reseed_primary_crng(void) > > +{ > > + if (crng_init > 2 && > > +

Re: [PATCH v6 0/5] /dev/random - a new approach

On Thu, Aug 18, 2016 at 08:39:23PM +0200, Pavel Machek wrote: > > But this is the scary part. Not limited to ssh. "We perform the > largest ever network survey of TLS and SSH servers and present > evidence that vulnerable keys are surprisingly widespread. We find > that 0.75% of TLS certificates

Re: [PATCH v6 0/5] /dev/random - a new approach

On Mon, Aug 15, 2016 at 08:13:06AM +0200, Stephan Mueller wrote: > > According to my understanding of NAPI, the network card sends one interrupt > when receiving the first packet of a packet stream and then the driver goes > into polling mode, disabling the interrupt. So, I cannot see any

Re: [PATCH v6 0/5] /dev/random - a new approach

On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote: > > - correlation: the interrupt noise source is closely correlated to the HID/ > block noise sources. I see that the fast_pool somehow "smears" that > correlation. However, I have not seen a full assessment that the correlation >

Re: [PATCH v6 0/5] /dev/random - a new approach

On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote: > > The following patch set provides a different approach to /dev/random which > I call Linux Random Number Generator (LRNG) to collect entropy within the > Linux > kernel. The main improvements compared to the legacy /dev/random

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

On Tue, Aug 09, 2016 at 02:04:44PM +, Jason Cooper wrote: > > iiuc, Ted, you're saying using the hw_random framework would be > disasterous because despite most drivers having a default quality of 0, > rngd assumes 1 bit of entropy for every bit read? Sorry, what I was trying to say (but

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote: > Agree with Jason's point, also understand Stephan's concern. The > date rate can be roughly estimated by 'cat /dev/random |rngtest -c > 1000', the average speed is .294Kibits/s. I will sent the patch > to disable ath9k RNG by

Re: getrandom waits for a long time when /dev/random is insufficiently read from

d on my previous statement, in this scenario, getrandom should > never block. This is correct; and it has been fixed in the patches in v4.8-rc1. The patch which fixes this has been marked for backporting to stable kernels: commit 3371f3da08cff4b75c1f2dce742d460539d6566d Author: Theodore Ts'o <ty.

[GIT PULL] /dev/random driver fix for 4.8

. Theodore Ts'o (1): random: use for_each_online_node() to iterate over NUMA nodes drivers/char/random.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe

Re: [GIT PULL] /dev/random driver changes for 4.8

On Mon, Jul 25, 2016 at 02:44:24AM -0400, Theodore Ts'o wrote: > The following changes since commit 1a695a905c18548062509178b98bc91e67510864: > > Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/l

Re: [GIT PULL] /dev/random driver changes for 4.8

On Mon, Jul 25, 2016 at 05:15:15PM +1000, Stephen Rothwell wrote: > Hi Ted, > > On Mon, 25 Jul 2016 02:44:24 -0400 Theodore Ts'o <ty...@mit.edu> wrote: > > > > The following changes since commit 1a695a905c18548062509178b98bc91e67510864: > > > > L

[GIT PULL] /dev/random driver changes for 4.8

random number generator (if present) to initialize the /dev/urandom pool. Eric Biggers (1): random: properly align get_random_int_hash Stephan Mueller (1): random: add interrupt callback to VMBus IRQ handler Theodore Ts'o (6

Re: [PATCH 7/7] random: add backtracking protection to the CRNG

On Sun, Jun 26, 2016 at 08:47:53PM +0200, Pavel Machek wrote: > > You are basically trying to turn CRNG into one way hash function here, > right? Do you have any explanation that it has the required > properties? Well, not really. A CRNG has the property that if you generate a series of

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Sun, Jun 26, 2016 at 08:47:43PM +0200, Pavel Machek wrote: > Ok, so lets say I'm writing some TLS server, and I know that traffic > is currently heavy because it was heavy in last 5 minutes. Would it > make sense for me to request 128M of randomness from /dev/urandom, and > then use that

Re: [PATCH v5 0/7] /dev/random - a new approach

On Mon, Jun 20, 2016 at 09:00:49PM +0200, Stephan Mueller wrote: > > The time stamp maintenance is the exact cause for the correlation: one HID > event triggers: > > - add_interrupt_randomness which takes high-res time stamp, Jiffies and some > pointers > > - add_input_randomness which takes

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 20, 2016 at 05:49:17PM +0200, Stephan Mueller wrote: > > Is speed everything we should care about? What about: > > - offloading of crypto operation from the CPU In practice CPU offland is not helpful, and in fact, in most cases is harmful, when one is only encrypting a tiny amount

Re: [PATCH v5 0/7] /dev/random - a new approach

On Mon, Jun 20, 2016 at 07:51:59AM +0200, Stephan Mueller wrote: > > - Correlation of noise sources: as outlined in [1] chapter 1, the three noise > sources of the legacy /dev/random implementation have a high correlation. > Such > correlation is due to the fact that a HID/disk event at the

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 20, 2016 at 01:19:17PM +0800, Herbert Xu wrote: > On Mon, Jun 20, 2016 at 01:02:03AM -0400, Theodore Ts'o wrote: > > > > It's work that I'm not convinced is worth the gain? Perhaps I > > shouldn't have buried the lede, but repeating a paragraph from lat

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 20, 2016 at 09:25:28AM +0800, Herbert Xu wrote: > > Yes, I understand the argument that the networking stack is now > > requiring the crypto layer --- but not all IOT devices may necessarily > > require the IP stack (they might be using some alternate wireless > > communications stack)

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Wed, Jun 15, 2016 at 10:59:08PM +0800, Herbert Xu wrote: > I think you should be accessing this through the crypto API rather > than going direct. We already have at least one accelerated > implementation of chacha20 and there may well be more of them > in future. Going through the crypto API

Re: [PATCH v4 0/5] /dev/random - a new approach

On Fri, Jun 17, 2016 at 03:56:13PM +0200, David Jaša wrote: > I was thinking along the lines that "almost every important package > supports FreeBSD as well where they have to handle the condition so > option to switch to Rather Break Than Generate Weak Keys would be nice" > - but I didn't expect

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 13, 2016 at 08:00:33PM +0200, Stephan Mueller wrote: > > 1. The ChaCha20 is seeded with 256 bits (let us assume it is full entropy) > > 2. The ChaCha20 block operation shuffles the 256 bits of entropy over the 512 > bit state -- already here we see that after shuffling, the entropy

[PATCH 6/7] random: make /dev/urandom scalable for silly userspace programs

it from running, lemming-like, straight over the locking cliff. Reported-by: Andi Kleen <a...@linux.intel.com> Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 62 +++ 1 file changed, 58 insertions(+), 4 deleti

[PATCH 3/7] random: add interrupt callback to VMBus IRQ handler

ntropy collector is not triggered. This patch adds the interrupt entropy collection callback into the VMBus interrupt handler function. Cc: sta...@kernel.org Signed-off-by: Stephan Mueller <stephan.muel...@atsec.com> Signed-off-by: Stephan Mueller <smuel...@chronox.de> Signed-off-by:

[PATCH 1/7] random: initialize the non-blocking pool via add_hwgenerator_randomness()

If we have a hardware RNG and are using the in-kernel rngd, we should use this to initialize the non-blocking pool so that getrandom(2) doesn't block unnecessarily. Cc: sta...@kernel.org Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 16 +++- 1 file c

[PATCH 2/7] random: print a warning for the first ten uninitialized random users

Since systemd is consistently using /dev/urandom before it is initialized, we can't see the other potentially dangerous users of /dev/urandom immediately after boot. So print the first ten such complaints instead. Cc: sta...@kernel.org Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- d

[PATCH 4/7] random: properly align get_random_int_hash

: Eric Biggers <ebigge...@gmail.com> Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 64e35a4..83f5cd0 100644 --- a/drivers/char/random.c +++ b/dri

[PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- crypto/chacha20_generic.c | 61 drivers/char/random.c | 374 +- include/crypto/chacha20.h | 1

[PATCH 7/7] random: add backtracking protection to the CRNG

Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 54 ++- 1 file changed, 49 insertions(+), 5 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d640865..963a6a9 100644 --- a/drivers/char/ra

Re: [PATCH-v3 0/5] random: replace urandom pool with a CRNG

On Mon, May 30, 2016 at 10:53:22AM -0700, Andi Kleen wrote: > > It should work the same on larger systems, the solution scales > naturally to lots of sockets. It's not clear it'll help enough on systems > with a lot more cores per socket, like a Xeon Phi. But for now it should > be good enough.

Re: [PATCH 2/5] random: make /dev/urandom scalable for silly userspace programs

On Mon, May 30, 2016 at 08:03:59AM +0200, Stephan Mueller wrote: > > static int rand_initialize(void) > > { > > +#ifdef CONFIG_NUMA > > + int i; > > + int num_nodes = num_possible_nodes(); > > + struct crng_state *crng; > > + > > + crng_node_pool = kmalloc(num_nodes * sizeof(void *), > >

[PATCH-v3 0/5] random: replace urandom pool with a CRNG

align the get_random_int_hash[] array Eric Biggers (1): random: properly align get_random_int_hash Stephan Mueller (1): random: add interrupt callback to VMBus IRQ handler Theodore Ts'o (3): random: replace non-blocking pool with a Chacha20-based CRNG random: make /dev/urandom scalable

[PATCH 5/5] random: properly align get_random_int_hash

lt;ebigge...@gmail.com> Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 860862f..90fb569 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@

[PATCH 2/5] random: make /dev/urandom scalable for silly userspace programs

it from running, lemming-like, straight over the locking cliff. Reported-by: Andi Kleen <a...@linux.intel.com> Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 57 +++ 1 file changed, 53 insertions(+), 4 deleti

[PATCH 1/5] random: replace non-blocking pool with a Chacha20-based CRNG

The CRNG is faster, and we don't pretend to track entropy usage in the CRNG any more. Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- crypto/chacha20_generic.c | 61 drivers/char/random.c | 350 ++ include/crypto/chacha20.h | 1

[PATCH 4/5] random: add backtracking protection to the CRNG

Signed-off-by: Theodore Ts'o <ty...@mit.edu> --- drivers/char/random.c | 52 ++- 1 file changed, 47 insertions(+), 5 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index bf370a3..860862f 100644 --- a/drivers/char/ra

Re: AES-NI: slower than aes-generic?

On Sun, May 29, 2016 at 09:51:59PM +0200, Stephan Mueller wrote: > > I personally am not sure that taking some arbitrary cipher and turning it > into > a DRNG by simply using a self-feeding loop based on the ideas of X9.31 > Appendix A2.4 is good. Chacha20 is a good cipher, but is it equally

Re: AES-NI: slower than aes-generic?

On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote: > > Using the kernel crypto API one can relieve the CPU of the crypto work, if a > hardware or assembler implementation is available. This may be of particular > interest for smaller systems. So, for smaller systems (where kernel

  1   2   >