Oh my. Apparently, AMD CPUs will sometimes return bad results from RDRAND after a suspend. That's bad, but if everyone has been following the cryptographer's advice and _just used getrandom()_ that's not a problem. ... nope! systemd of course didn't!https://github.com/systemd/systemd/issues/11810#issuecomment-489727505 …
-
Show this thread
-
Replying to @FiloSottile
I think you're misreading the source here. Systemd _does_ call getrandom() if the syscall is available + adds an RDRAND seed on top (if explicitly enabled) and only pads with pseudorandom bytes if getrandom() returns EGAIN (no entropy)
2 replies 0 retweets 1 like -
Replying to @ProgrammerDude
I am staring at it, and I can't see how RANDOM_ALLOW_RDRAND does not lead to plain RDRAND output, which is apparently what caused the user-reported issue.
2 replies 0 retweets 2 likes -
Replying to @FiloSottile @ProgrammerDude
There'd be no real harm in generating 256 bits of entropy by doing the dirty "flip a bit for approximately 100 nanos and take the final value" trick and mixing that it in. Along with clock values and HWIDs.
2 replies 0 retweets 0 likes
But really /dev/random should do this anyway, and never ever block. User-Space shouldn't be thinking they need to work around anything. Kernel CSPRNGs are just full of insane beliefs about entropy.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.