Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux RNG flaws

bugs.chromium.org

Post reply on HN
Print view View original

21–30 of 67 posts

Re: Linux RNG flaws

#21

Post by tankenmate »

amelius wrote: post #18
zaarn wrote: post #15

Earlier quoted context omitted.

I think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG. Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves. But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)

Why doesn't the device simply block until it has collected sufficient randomness?

Chicken and egg; it won't properly boot until it has enough entropy, and you don't get enough entropy until it is booted.

The proper fix is to change the boot scripts to not assume that the CRNG will be available directly after boot.

Re: Linux RNG flaws

#22

Post by lihes »

man urandom

> When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized.

I see no bugs here. Just repeating what is written in the man page.

Re: Linux RNG flaws

#23

Post by zaarn »

amelius wrote: post #18
zaarn wrote: post #15

Earlier quoted context omitted.

I think that problem could be handled by having the RNG return an error until crng_init=2 and introduce a way to check the state of the kernel RNG. Applications can then check if the kernel is ready to do RNG and if not, handle the delay themselves. But I guess that would break some applications so there might be another way (extra device for early boot randomness? ioctl?)

Why doesn't the device simply block until it has collected sufficient randomness?

/dev/random kinda does but a lot of applications also rely on /dev/urandom which doesn't, which is why it's a problem to some extend.

Atleast from what I know.

Re: Linux RNG flaws

#24

Post by therein »

tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

> So for some hardware, and some distributions, we're getting some boot hangs that we now need to try to workaround or fix somehow.

I recently updated to a 4.x series kernel and had this issue during boot. I had to interact with the VM to get it to unblock and boot.

Re: Linux RNG flaws

#25

Post by jakeogh »

tankenmate wrote: post #21
amelius wrote: post #18

Earlier quoted context omitted.

Why doesn't the device simply block until it has collected sufficient randomness?

Chicken and egg; it won't properly boot until it has enough entropy, and you don't get enough entropy until it is booted. The proper fix is to change the boot scripts to not assume that the CRNG will be available directly after boot.

It's better to deadlock than to revert to a weak RNG. Deadlocking guarantees the application gets fixed. Reminds me of setting an init system to restart crashed daemons.

Re: Linux RNG flaws

#26

Post by anon1385 »

lihes wrote: post #22

man urandom > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. I see no bugs here. Just repeating what is written in the man page.

Keep in mind that a lot of high profile security people on HN and elsewhere have spent many years now telling everybody that the linux urandom man page is wrong, so don't be surprised when people ignore it.

https://hn.algolia.com/?query=urandom%20manpage&sort=byPopul...

Re: Linux RNG flaws

#27

Post by chopin »

hsivonen wrote: post #12
IcePic wrote: post #11

Earlier quoted context omitted.

There is no reason not to try it, but you would still want to cater for the initial boot when you have no previous entropy to read.

Couldn't the installer write the initial seed?

There's not always an installer, I make heavily use of live images. On other machines of mine, first boot is made from a copied image.

Re: Linux RNG flaws

#28

Post by acd »

tytso wrote: post #8

The flaws only applied for keys generated during early boot. Jann and I looked, but we didn't find a way that this could be turned into a practical exploit, which is why we considered, but decided against, doing any kind of coordinated disclosure. The potential weakness applies before you see crng_init=2 message, and in practice on many machines this happens well before a minute --- on my laptop, in under 10 seconds.…

In cloud during new machine install ssh host keys are generated during boot time well under a minute. Say that the virtual host machine that hosts the virtual machines writes the disk image to local disk, the disk image is then in cache memory on the virtual host, the virtual machine boots from what is essentially a file in RAM cache or a fast SSD.

Re: Linux RNG flaws

#29

Post by jwilk »

lihes wrote: post #22

man urandom > When read during early boot time, /dev/urandom may return data prior to the entropy pool being initialized. I see no bugs here. Just repeating what is written in the man page.

Please don't post shallow dismissals.

None of the reported bugs are about /dev/urandom returning data too early.

Re: Linux RNG flaws

#30

Post by amelius »

jakeogh wrote: post #25
tankenmate wrote: post #21

Earlier quoted context omitted.

Chicken and egg; it won't properly boot until it has enough entropy, and you don't get enough entropy until it is booted. The proper fix is to change the boot scripts to not assume that the CRNG will be available directly after boot.

It's better to deadlock than to revert to a weak RNG. Deadlocking guarantees the application gets fixed. Reminds me of setting an init system to restart crashed daemons.

Or how about it blocks, and then if the user starts rambling on the keyboard, it collects entropy?
Post reply on HN