Skip to contentSkip to conversation

random: fix the RNDRESEEDCRNG ioctl

PATCH Superseded Eric Biggers 2 participants 7 messages Sep 16, 2020 – Jan 12, 2021

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 random: fix the RNDRESEEDCRNG ioctl

From: Eric Biggers <[email protected]>

The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead.

Fixes d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
---
 drivers/char/random.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/random.c +1 -1
index d20ba1b104ca3..a8b9e66f41435 100644
@@ -1973,7 +1973,7 @@ static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
 			return -EPERM;
 		if (crng_init < 2)
 			return -ENODATA;
-		crng_reseed(&primary_crng, NULL);
+		crng_reseed(&primary_crng, &input_pool);
 		crng_global_init_time = jiffies - 1;
 		return 0;
 	default:
Signature · 1 line
2.28.0
#3 lore raw
Quoted 7 lines · Eric Biggers
Quoted 6 lines · Eric Biggers
Quoted 5 lines · Eric Biggers

From: Eric Biggers <[email protected]>

The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead.

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Fixes d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")

Ping?

Ping.

Ping.

#4 lore raw
Quoted 12 lines · Eric Biggers
Quoted 11 lines · Eric Biggers
Quoted 10 lines · Eric Biggers
Quoted 8 lines · Eric Biggers

From: Eric Biggers <[email protected]>

The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead.

Fixes d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Quoted 5 lines
Quoted 3 lines
Quoted 1 line

Ping?

Ping.

Ping.

Ping.

#5 lore raw
Quoted 13 lines · Eric Biggers
Quoted 12 lines · Eric Biggers
Quoted 11 lines · Eric Biggers
Quoted 10 lines · Eric Biggers
Quoted 8 lines · Eric Biggers

From: Eric Biggers <[email protected]>

The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead.

Fixes d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line

Ping?

Ping.

Ping.

Ping.

You may want to resend to akpm with a note that the maintainer is unresponsive.

Reviewed-by on v1 1/1
#6 lore raw
In reply to Eric Biggers
Quoted 2 lines · Eric Biggers

The RNDRESEEDCRNG ioctl reseeds the primary_crng from itself, which doesn't make sense. Reseed it from the input_pool instead.

Good catch. (And its purpose is to ensure that entropy from random_write() is plumbed all the way through such that getrandom() and friends are guaranteed to actually use that entropy on the next invocation; and random_write() just puts data into the input pool.)

But actually, looking at the surrounding code, I think there's another small problem?

Quoted 3 lines
Fixes d848e5f8e1eb ("random: add new ioctl RNDRESEEDCRNG")
Quoted 9 lines
---
 drivers/char/random.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/char/random.c +0 -0
index d20ba1b104ca3..a8b9e66f41435 100644

drivers/char/random.c static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg) · line 1976

Quoted 5 lines
drivers/char/random.c +1 -1
@@ -1973,7 +1973,7 @@ static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
                        return -EPERM;
                if (crng_init < 2)
                        return -ENODATA;
-               crng_reseed(&primary_crng, NULL);
+               crng_reseed(&primary_crng, &input_pool);

So now this will pull the data from the input_pool into the primary_crng, so far so good...

drivers/char/random.c static long random_ioctl(struct file *f, unsigned int cmd, unsigned long arg) · line 1977

Quoted 1 line
drivers/char/random.c +0 -0
                crng_global_init_time = jiffies - 1;

... and this will hopefully cause _extract_crng() to pull from the primary_crng into crng_node_pool[numa_node_id()] afterwards. Unless things are going too fast and therefore the jiffies haven't changed since the last crng_reseed() on the crng_node_pool[numa_node_id()]... a sequence number would probably be more robust than a timestamp.

And a plain write like this without holding any locks is also questionable.

The easiest way would probably be to make it an atomic_long_t, do atomic_long_inc() instead of setting crng_global_init_time here, and check atomic_long_read(...) against a copy stored in the crng_state on _extract_crng()? And in crng_reseed(), grab the global sequence number at the start, then do smp_rmb(), and then under the lock do the actual reseeding and bump ->init_time? Or something like that?

Quoted 2 lines
drivers/char/random.c +0 -0
                return 0;
        default: