[Buildroot] [PATCH v2] package/urandom-scripts: hash old seed with new seed when saving

[Eugen.Hristev at microchip.com]

On 3/28/22 4:17 PM, Peter Korsgaard wrote:
>>>>>> "Yann" == Yann E MORIN <yann.morin.1998 at free.fr> writes:
> 
>   > Jason, All,
>   > +Peter: candidate for backporting as a security fix
> 
>   > On 2022-03-23 14:07 -0600, Jason A. Donenfeld spake thusly:
>   >> Writing into /dev/urandom doesn't actually credit any entropy bits. And
>   >> while it adds that data to the entropy pool, it won't actually be
>   >> immediately used when reading from /dev/urandom subsequently. This is
>   >> how the kernel's /dev/urandom has always worked, unfortunately.
>   >>
>   >> As a result of this behavior, which may be understandably surprising,
>   >> writing a good seed file into /dev/urandom and then saving a new seed
>   >> file immediately after is dangerous, because the new seed file may wind
>   >> up being entirely deterministic, even if the old seed file was quite
>   >> good.
>   >>
>   >> This has been fixed in systemd with
>   >> <https://github.com/systemd/systemd/commit/da2862ef06f22fc8d31dafced6d2d6dc14f2ee0b>,
>   >> and fortunately it's possible to do the same thing in shell script here.
>   >> Specifically, instead of just saving new /dev/urandom output straight
>   >> up, we hash the new /dev/urandom together with the old seed, in order to
>   >> produce the new seed. This way the amount of entropy in the new seed
>   >> will stay the same or get better, but not appreciably regress.
>   >>
>   >> At the same time, the pool size check in this script is useless. Writing
>   >> to /dev/urandom never credits bits anyway, so no matter what, writing
>   >> into /dev/urandom is useful and not harmful. There's also not much of a
>   >> point in seeding with more than 256 bits, which is what the hashing
>   >> operation above produces. So this commit removes the file size check.
>   >>
>   >> As a final note, while this commit improves upon the status quo by
>   >> removing a vulnerability, this shell script still does not actually
>   >> initialize the RNG like it says it does. For initialization via a seed
>   >> file, the RNDADDENTROPY ioctl must be used.
>   >>
>   >> Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
> 
>   > Applied to master, thanks.
> 
> Committed to 2021.02.x and 2022.02.x, thanks.

Hello Jason,

I noticed that you worked a lot on the S20urandom init script for 
sysvinit in buildroot.

I recently updated from 2022.02 release to 2022.02.1 and now on booting 
all our boards, I noticed this message:

"Initializing random number generator: FAIL"


With the 2022.02 release, with the same kernel, the message stated "OK".

So it might be something changed on this BR revision that causes this fail.

As you worked more on these scripts , do you have maybe an idea or a 
hint about what I can try , to have it working as before ?
Or maybe what change can cause it ?

I tried to test 2022.02 + this patch I am replying to, and things appear 
to work fine. So it must be something else then...

Thank you for your help !

Eugen

> 
> --
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
>