Announcement

Collapse
No announcement yet.

Linux 5.4 Will Try When Needed To Actively Generate RNG Entropy To Avoid Boot Problems

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

  • Linux 5.4 Will Try When Needed To Actively Generate RNG Entropy To Avoid Boot Problems

    Phoronix: Linux 5.4 Will Try When Needed To Actively Generate RNG Entropy To Avoid Boot Problems

    Linux 5.4-rc1 didn't end up being released on Sunday night as is tradition but instead there were some last-minute critical patches that landed around the kernel's handling of the random number generator / entropy at boot-time...

    http://www.phoronix.com/scan.php?pag...ly-Gen-Entropy

  • #2
    Originally posted by phoronix View Post
    GNOME/GDM requesting secure randomness at boot time,
    But why? Is that really necessary?

    Comment


    • #3
      Originally posted by tildearrow View Post

      But why? Is that really necessary?
      Well, if you look more carefully, you notice the real culprit was Ext4. So this is mostly a "don't break userspace" thing rather than just responding to pleads from userspace developers to add this.

      Comment


      • #4
        Originally posted by tildearrow View Post
        But why?
        Secure key rings, encrypted virtual filesystems, and whatnot.

        Is that really necessary?
        Yes or someone wouldn't be using it.

        Comment


        • #5
          Originally posted by tildearrow View Post
          But why? Is that really necessary?
          Seems like a bug.

          https://git.kernel.org/pub/scm/linux...39da47ec689e55

          This is admittedly partly "for discussion". We need to have a way forward for the boot time deadlocks where user space ends up waiting for more entropy, but no entropy is forthcoming because the system is entirely idle just waiting for something to happen.

          While this was triggered by what is arguably a user space bug with GDM/gnome-session asking for secure randomness during early boot, when they didn't even need any such truly secure thing, the issue ends up being that our "getrandom()" interface is prone to that kind of confusion, because people don't think very hard about whether they want to block for sufficient amounts of entropy.

          The approach here-in is to decide to not just passively wait for entropy to happen, but to start actively collecting it if it is missing. This is not necessarily always possible, but if the architecture has a CPU cycle counter, there is a fair amount of noise in the exact timings of reasonably complex loads.

          We may end up tweaking the load and the entropy estimates, but this should be at least a reasonable starting point.

          As part of this, we also revert the revert of the ext4 IO pattern improvement that ended up triggering the reported lack of external entropy.

          Comment


          • #6
            Originally posted by skeevy420 View Post

            Secure key rings, encrypted virtual filesystems, and whatnot.



            Yes or someone wouldn't be using it.
            Torvalds disagrees (see above)

            Comment


            • #7
              Originally posted by starshipeleven View Post

              Torvalds disagrees (see above)
              I saw that, but, IMHO, I can't really blame Gnome for wanting to try to be as secure as possible and erring on the side of caution in this day and age.

              Besides, while whatever Gnome is using it for apparently doesn't need it, it's great that more eyes on a topic found a bug that could have hindered a systemd service, LUKS, etc that actually does need it and is what makes open source great.

              Comment


              • #8
                Originally posted by skeevy420 View Post
                I saw that, but, IMHO, I can't really blame Gnome
                I don't know and I'm not automatically assuming they really need it. There are plenty of applications that need randomness for non-security purposes and would be totally fine with low quality entropy.

                more eyes on a topic found a bug that could have hindered a systemd service
                That's like a year or so too late for that. System hangs on boot (with systemd and other things that actually need the entropy) because of lack of entropy were first reported ages ago.
                Sane distros are already shipping daemons like haveged or rngd that fill the pool with lower-quality entropy.

                Comment


                • #9
                  Originally posted by skeevy420 View Post

                  Secure key rings, encrypted virtual filesystems, and whatnot.



                  Yes or someone wouldn't be using it.
                  Do we need randomness to read an encrypted filesystem? I've heard it may be needed for writes, but what about reads?

                  Comment


                  • #10
                    Originally posted by tildearrow View Post

                    Do we need randomness to read an encrypted filesystem? I've heard it may be needed for writes, but what about reads?
                    Don't know, I'm not really all that sure on the ins and outs of encryption to know one way or the other outside of generic crap like "fast and randomized entropy = good" & "1024 > 512"...

                    Comment

                    Working...
                    X