Thread

1. jstanley · 1790072957 · focus · HN ↗

   This is not the first RNG bug on Zen 2, I recall after I first got mine that some application or other would quit immediately at startup because rdrand always returned -1, i.e. all 1s. It was fixed with a microcode update.

   Do we now learn that they fixed "always generate all 1s" with "never generate all 0s"??

   EDIT: I've been unable to reproduce the problem on my CPU, FWIW. It's a Ryzen 5 3600.

   EDIT2: OK, update, I can reproduce it with rdrand16, rdrand32 is fine but rdrand16 can never generate all 0s. So my CPU does have this problem!

   1. jamesponddotco · 1790083217 · focus · HN ↗

      If I remember correctly, we had a setting in every Linux server we owned to remove CPU as a RNG seeder for the kernel because of those bugs with AMD CPUs.

      I.e., we had `random.trust_cpu=off nordrand` in `GRUB_CMDLINE_LINUX`.

      1. knorker · 1790083770 · focus · HN ↗

         Adding bad randomness can't degrade good randomness, can it?

         I thought the kernel would not replace anything just because it adds a potentially bad source.

         E.g. if you have rand source A, and xor it with rand source B, then you get, at worst, the best of A and B,

         1. leni536 · 1790105640 · focus · HN ↗

            > E.g. if you have rand source A, and xor it with rand source B, then you get, at worst, the best of A and B,

            With the assumption that sources A and B are independent from each other.

            1. knorker · 1790106262 · focus · HN ↗

               Sure. In general this is a very important factor.

               In the context of this topic, it's a bit pedantic.

               1. leni536 · 1790323220 · focus · HN ↗

                  Even if the assumption is reasonable, it is worth explicitly spelling out.

Unofficial Hacker News client; not affiliated with Y Combinator.