> On Dec 29, 2019, at 10:49 PM, Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > > On Fri, Dec 27, 2019 at 06:06:56PM -0800, Andy Lutomirski wrote: >> >> I'm thinking of having a real class device and chardev for each hwrng >> device. Authentication is entirely in userspace: whatever user code >> is involved can look at the sysfs hierarchy and decide to what extent >> it trusts a given source. This could be done based on bus topology or >> based on anything else. > > Yes, that's what I was thinking. Another project on my "when I can > get a round tuit" list is to change how drivers/char/random.c taps > into the hwrng devices, mixing in a bit from each of these devies in a > round-robin fashion, instead of just feeding from a single hwrng. > >> The kernel could also separately expose various noise sources, and the >> user code can do whatever it wants with them. But these should be >> explicitly unconditioned, un-entropy-extracted sources -- user code >> can run its favorite algorithm to extract something it believes to be >> useful. The only conceptually tricky bit is keeping user code like >> this from interfering with the in-kernel RNG. > > The other problem is the unconditioned values of the noise sources may > leak unacceptable amounts of information about system operation. The > most obvious example of this would be keyboard and mouse sources, > where today we mix in not only the timing information, but the actual > input values (e.g., the keyboard scancodes) into the entropy pool. > Exposing this to userspace, even if it is via a privileged system > call, would be... unwise. > > Hmm. We could give only the timing. We could also say that the official interface for this is to use tracepoints and punt everything into userspace.
