Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Friday December 21 2018, @06:19PM   Printer-friendly
from the chaos-monkey dept.

Recent upgrades that depend on the new Linux getrandom() syscall can cause OpenSSH to delay starting for tens of minutes while waiting for enough bytes of randomness. There are currently not any feasible work-arounds.

Systemd makes this behaviour worse, see issue #4271, #4513 and #10621.
Basically as of now the entropy file saved as /var/lib/systemd/random-seed will not - drumroll - add entropy to the random pool when played back during boot. Actually it will. It will just not be accounted for. So Linux doesn't know. And continues blocking getrandom(). This is obviously different from SysVinit times when /var/lib/urandom/random-seed (that you still have laying around on updated systems) made sure the system carried enough entropy over reboot to continue working right after enough of the system was booted.

#4167 is a re-opened discussion about systemd eating randomness early at boot (hashmaps in PID 0...). Some Debian folks participate in the recent discussion and it is worth reading if you want to learn about the mess that booting a Linux system has become.

While we're talking systemd ... #10676 also means systems will use RDRAND in the future despite Ted Ts'o's warning on RDRAND [Archive.org mirror and mirrored locally as 130905_Ted_Tso_on_RDRAND.pdf, 205kB as Google+ will be discontinued in April 2019].

Related post: OneRNG: a Fully-Open Entropy Generator (2014)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by Thexalon on Saturday December 22 2018, @01:25PM (2 children)

    by Thexalon (636) on Saturday December 22 2018, @01:25PM (#777520)

    You can't, that's the point. There's no way to really measure entropy, you can only estimate it. If you get it from a file you have no idea what the quality is.

    Then estimate it, and see what the estimate is.

    The only way to "generate" entropy is to wait for it to accumulate as the kernel runs, hence the multiple minute waits after boot. You're asking systemd to do what it's already doing.

    I'm asking systemd to do what it's already doing when it's actually necessary to do that, not when it is theoretically conceivable that doing that might be required.

    Lennart is worried about people rolling their own things, like embedded.

    So you're saying that folks are smart enough to roll their own, but dumb enough to get the entropy file wrong (presumably, the issue gets discussed in any books / websites / other resources they're consulting when rolling their own), and for that reason you should do something very annoying for the vast majority of users who aren't rolling their own?

    Again, it's taking a theoretical issue and using it as an excuse to mess things up for everybody who isn't affected by it. Lennart has busted the kernel for similar reasons before.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.
    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by Pino P on Saturday December 22 2018, @08:42PM

    by Pino P (4721) on Saturday December 22 2018, @08:42PM (#777651) Journal

    Then estimate it, and see what the estimate is.

    This exposes the system to RNG attacks [wikipedia.org] in which the attacker replaces the seed file with a hand-crafted one that games the estimate.

    folks are smart enough to roll their own, but dumb enough to get the entropy file wrong

    Yes. See the "Prominent examples" in the "RNG attacks" article.

  • (Score: 2) by darkfeline on Wednesday December 26 2018, @01:15AM

    by darkfeline (1030) on Wednesday December 26 2018, @01:15AM (#778453) Homepage

    Let me just give you a very simple example.

    Take a "good" seed file. The first time this file is ever used in history, it has N bits of good entropy. Every subsequent time it is used, it has 0 bits of good entropy.

    Now, tell me how systemd is supposed to estimate whether the seed file was ever used before in history? It might not even have been used on the same computer, or on the same drive, or in the same country.

    This isn't a theoretical issue. Have you heard of Logjam, where everyone shipped a common Diffie-Hellman prime opening up an attack vector? Most people screw up cryptosystems, including distro maintainers and packagers.

    Even IF we accept the risk, to dismiss Lennart's position off-hand is disingenuous. He has a valid point even if you disagree with it for valid reasons.

    >So you're saying that folks are smart enough to roll their own, but dumb enough to get the entropy file wrong

    All it takes to "roll their own" is to take an image snapshot of the disk, like for an embedded project. You don't even have to know about the seed file to get it wrong. In fact, it's the opposite: the people who don't even know about the seed file's existence are the most likely to get it wrong. If you do know about it, you're able to optionally enable it in systemd if you need it.

    --
    Join the SDF Public Access UNIX System today!