If you block on FG (~7kB/s) for these, your machine will run like 386, I suspect.

I'm not so much concerned about this: if it's too slow, the conclusion would be "Linux does not work nicely with the HWRNG"; and anyway I don't think Linux will use more than 2kB/s or RNG data for it's internal use.

#19

Re: tests -- at the very least you want a machine-wide alarm that tells you if the thing went unplugged, or somehow fell substantially below spec output rate, etc.

This I can see.

@Mircea Popescu,

There's a blocking and a non-blocking kernel pool. Let them stand as such.

Point taken.

Meanwhile, comments here should be fixed.

Yes, but that was for TMSR-os, not for confiscated-Linus item.

Review what that blond fuck did when he ruined the kernel for you, and do the same thing to him. FG in kernel so all the jwzs use it by default. And in general -- republic by default is the crowd control strategy.

> You already have a led for catastrophic failures neh ?

With naked eye, can see the one on desk, but not e.g. the ones at piz...

> There's a blocking and a non-blocking kernel pool

I actually liked your earlier idea , where entirely abolish '/dev/urandom' nonblocking pool.

> no don't make it spuriously shittier by "testing" unasked

Seems like cogent argument for leaving the matter entirely out of the kernel. Let user test when he wants, how he wants, decide how many bits he can afford to burn away.

I can see an argument for 'kernel cuts FG bitstream among N users' but that's about it.

And if you want to ~waste~ some bits to spuriously test, all your other arguments suddenly suffer. There's a blocking and a non-blocking kernel pool. Let them stand as such ; and yes if this means proc is running as 386 let it run as 386 ; and no don't make it spuriously shittier by "testing" unasked.

> this means sharing the secret bits with the measurer, which meh

I thought this was obv., but why would you ever test *and give out to eating process* a particular string of bytes? You test periodic selections, like in most industrial process, these then get discarded.

> ASLR, stack protector, freelist randomization, certain debug paths and self-tests

If you block on FG (~7kB/s) for these, your machine will run like 386, I suspect.

@Mircea Popescu:

> How's entropy supposed to be automatically measured anyways

Pretty sure we went over this at some point in '16 -- the utility of simple "smoke" tests like "ent" in case like this is to detect catastrophic failures (e.g. "oops, that ain't a FG, but is my Hayes 56K") rather than to make fine distinctions. Whether this belongs in kernel space is separate q, but IMHO any time FG output is being pooled, XOR'd, whichever manipulations, there ought to be a simple test that at least wakes up operator if somehow result is e.g. stream of 0.

> The whole fucking point of the exercise is to make it part of kernel

IMHO the ultimate q is, what part of FG eating, if any, actually wins from happening in kernel.

I will fix the comments on my blog in meantime.