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)
-
-
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 -
Replying to @colmmacc @ProgrammerDude
Oh but it is! With the right flags, getrandom() will not block, and urandom doesn't either. And the kernel does mix in all sort of stuff. Strong full agree that the blocking behavior is madness, and the source of a lot of these issues.
2 replies 0 retweets 12 likes -
Replying to @FiloSottile @ProgrammerDude
With the right flags is the problem! Developers end up thinking there's something lesser about urandom. I just want to nuke it all from orbit. Generating terabits of secure randomness does not take much entropy!
3 replies 0 retweets 4 likes -
Replying to @colmmacc @ProgrammerDude
I don't have the energy right now to lobby for just replacing /dev/random with a version of /dev/urandom that just blocks on boot, and to make the silly-blocking flag to getrandom() a no-op, but I will sign a support letter if you do!
1 reply 0 retweets 9 likes
I'll take signatures, but I'm pushing for more; I wouldn't even block on boot is what I'm saying. I'd burn a kernel thread for a few microseconds super early in the boot phase.
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.