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 -
-
Replying to @FiloSottile @ProgrammerDude
I'm not! That stuff is 100% safe to mix in to a DRBG, it can't make it any worse, and is defensive when the primary source is broken.
1 reply 0 retweets 0 likes -
Replying to @colmmacc @ProgrammerDude
That kind of over-thinking is what leads to the code this thread is about. I'm sure you don't consider HASH(time, HWID, bit flip) *sufficient*, but some systemd developer will in the EAGAIN branch. The message must be "just use getrandom or urandom", which *is* sufficient.
2 replies 1 retweet 13 likes -
Replying to @FiloSottile @ProgrammerDude
Like I said, this should be in the kernel :) The kernel should never, ever, ever, ever, block. /dev/random, /dev/urandom, getrandom(), getentropy() ... none of them! It's madness.
2 replies 0 retweets 4 likes
The attacks against the bit-flip method don't apply if it's happening in ring 0 as the system is booted. It's effectively a measure of HW clock and CPU precision. I still wouldn't call it sufficient on its own, but it's a good start before more interrupts can be timed.
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.