On 26/07/22 08:20, Jason A. Donenfeld wrote: > Hey Florian, > > On Tue, Jul 26, 2022 at 01:12:28PM +0200, Florian Weimer wrote: >>>> What happens if /dev/random is actually /dev/urandom? Will the poll >>>> call fail? >>> >>> Yes. I'm unsure if you're asking this because it'd be a nice >>> simplification to only have to open one fd, or because you're worried >>> about confusion. I don't think the confusion problem is one we should >>> take too seriously, but if you're concerned, we can always fstat and >>> check the maj/min. Seems a bit much, though. >> >> Turning /dev/random into /dev/urandom (e.g. with a symbolic link) used >> to be the only way to get some applications working because they tried >> to read from /dev/random at a higher rate than the system was estimating >> entropy coming in. We may have to do something differently here if the >> failing poll causes too much breakage. > > The "backup plan" would be to sleep-loop-read /proc/sys/kernel/random/entropy_avail > until it passes a certain threshold one time. This might also work on even older > kernels than the poll() trick. But that's pretty darn ugly, so it's not > obvious to me where the cut-off in frustration is, when we throw our > hands up and decide the ugliness is worth it compared to whatever > problems we happen to be facing at the time with the poll() technique. > But at least there is an alternative, should we need it. I think the poll trick is way better, although I also think it is very Linux specific. Should we move it to Linux sysdeps? The /proc/sys/kernel/random/entropy_avail would require to open another file descriptor, which I think we avoid for arc4random if possible.
