Announcement

Collapse
No announcement yet.

Some AMD CPUs Might Lose RdRand Randomness Following Suspend/Resume

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Some AMD CPUs Might Lose RdRand Randomness Following Suspend/Resume

    Phoronix: Some AMD CPUs Might Lose RdRand Randomness Following Suspend/Resume

    Systemd developers are sounding the alarms that some AMD processors might lose randomness (yielding non-random data) via the RdRand instruction following a suspend/resume alarm. However, initial indications don't appear for this to be some glaring widespread issue and might be limited to the older AMD CPUs and/or BIOS/motherboard combination...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    That error kind of suggest the RdRand implimentation in those processors is software based, and thus has a state that can be zeroed and made predictable. Either that or some combo where a pseudo-random generator is feed from a true (thermal) random source, but only on powerup(??)

    Comment


    • #3
      Originally posted by carewolf View Post
      That error kind of suggest the RdRand implimentation in those processors is software based, and thus has a state that can be zeroed and made predictable. Either that or some combo where a pseudo-random generator is feed from a true (thermal) random source, but only on powerup(??)
      easy there. It might just be that the BIOS driver does not initialize properly the thing on resume.

      Comment


      • #4
        IRONY=True
        Intel does not need suspend resumebto enable this "feature"
        IRONY=False

        Torvalds shoots down call to yank 'backdoored' Intel RdRand in Linux crypto
        'We actually know what we are doing. You don't' says kernel boss
        By Gavin Clarke 10 Sep 2013

        Comment


        • #5
          Originally posted by starshipeleven View Post

          easy there. It might just be that the BIOS driver does not initialize properly the thing on resume.
          It could easily be. I was just wondering _why_ it needed initialization.

          Comment


          • #6
            In testing I found the RdRand implementation in Ryzen to be pretty slow anyways. I had already set the "nordrand" kernel parameter on all my Linux boxes to boost entropy generation. Looks like I was going down the right path.

            There has been a lot of healthy debate over the need to include rdrand as an entropy source anyways.

            Comment


            • #7
              Originally posted by carewolf View Post

              It could easily be. I was just wondering _why_ it needed initialization.
              Could be something simple like bias level calibration, or something more Intel-esque like a non-random debug mode being entered. Without detailed info on the chip design, no way to know -- which is also why such RNGs should not be trusted for sensitive applications.

              Comment


              • #8
                It might be that the seed value from the entropy conditionner is no longer updated after resume.

                I read this: http://developer.amd.com/wordpress/m...or-Library.pdf

                Didn't understand much of it, but someone smarter than me might figure it out. This bug was reported from at least 2014.

                Comment


                • #9
                  Originally posted by AndyChow View Post
                  That is for Zen. The problem is pre-Zen.

                  Comment


                  • #10
                    Not a big problem, the Excavator-based CPUs weren't very popular...

                    Comment

                    Working...
                    X