Comments on: Bits and pieces of Linux RNG

By: bvt

bvt — Thu, 26 Sep 2019 19:55:58 +0000

When calling read(2) for the device /dev/urandom, reads of up to 256 bytes will return as many bytes as are requested and will not be interrupted by a signal handler.
E.g., a technically compliant program might not check the returned byte count, and pass off uninitialized bufferolade as entropy if fed from a tty. And in further sad,

Yes, this is a sad assumption, and I will take this into account in the new RNG.

Reads from this device do not block (i.e., the CPU is not yielded).

It indeed does not block, but does yield the CPU -- the call to schedule() in extract_crng_user allows other processes to run on the core. In this context, the link from /dev/ttyUSBx to /dev/urandom will still work unless the process does something braindamaged - I even can't come up a case when the application would care about the fact whether it blocked or not when reading from the device (for which there is explicit documentation that reads do not block). The latency is not an issue because FG continuously supplies fresh random bits. And anyhow, above applies only to urandom, for which the new design also uses CPRNG.

By: Jacob Welsh

Jacob Welsh — Thu, 26 Sep 2019 01:46:32 +0000

Removing the /dev/random node and replacing it with a hard-link to /dev/fg (or /dev/ttyUSB0, assuming your FG is connected via USB);

I've tried this experiment (as mentioned elsewhere) for feeding GPG, which reads from both random and urandom. It works, but there's a pitfall for using with arbitrary programs, per random(4):

When calling read(2) for the device /dev/urandom, reads of up to 256 bytes will return as many bytes as are requested and will not be interrupted by a signal handler.

E.g., a technically compliant program might not check the returned byte count, and pass off uninitialized bufferolade as entropy if fed from a tty. And in further sad,

Reads from this device do not block (i.e., the CPU is not yielded)

which would seem impossible to satisfy with FG, though I'm not sure of the implications.

By: bvt

bvt — Fri, 23 Aug 2019 21:54:14 +0000

@Stanislav,
The interrupt handlers should not require randomization (i.e. they are not entropy consumers), it's their timing (in jiffies and CPU cycles) that is used as a randomness source.

By: Stanislav Datskovskiy

Stanislav Datskovskiy — Fri, 23 Aug 2019 03:27:34 +0000

@bvt / 2 : currently I suspect that nuking the PRNG will expose -- at the very least -- interesting bugs in the interrupt handlers. (Why do these demand randomization to begin with?)

By: bvt

bvt — Thu, 22 Aug 2019 19:44:58 +0000

I think we now have a plan to follow. Re. experiments:
1. This would affect only userspace applications, the kernel entropy users will still be using the old infrastructure. Other than that, and exotica a la haveged/rngd, this should work.
2. This is certainly interesting - what other interfaces provided to userspace by kernel malfunction without entropy? Though this change may indeed affect too many places in the kernel, if done properly. The easiest hacky way to achieve this would seem to be disabling entropy collection functions; but crng that backs in-kernel users is designed to be available even when zero entropy is available in entropy pools, so no, this strawman does not work. (And funnily enough, urandom_init_wait is totally unused.)

By: spyked

spyked — Thu, 22 Aug 2019 07:59:01 +0000

IMHO it would be worth trying out (similarly to how Mircea Popescu points out) the following experiments:

* Removing the /dev/random node and replacing it with a hard-link to /dev/fg (or /dev/ttyUSB0, assuming your FG is connected via USB); and
* Trying to disable "randomness" altogether in the Linux kernel and seeing what effect this has on a. kernel compilation; and b. user space

The second experiment might take a lot of work, since from what I see there's no Kconfig "CONFIG_RANDOM" knob, as you'd expect -- after all, /dev/random is not even a POSIXism, so the impossibility to build a kernel without it is mind-boggling.