[onerng talk] Linux /dev/random changes on the way ...

[tmp543901 at buckeye-express.com]

On 2020-01-16 4:23 pm, Paul Campbell wrote:
> One issue I've had with recent kernels (prior to this) is that the 
> parameter:
> 
> /proc/sys/kernel/random/urandom_min_reseed_secs
> 
> has been broken - before the unified kernel entropy pool was 
> implemented this
> used to trigger copying new entopy into the kernel - setting it to 0 
> caused
> data to be fetched from OneRNG every second (you would see the LED 
> blink at
> that rate) - maybe the solution is to provide a patch to Linus that
> reimplements this.

I'm on kernel 4.9 which is broken as you describe.  Without using the 
tickler
script (blip.py) my OneRNG just sits doing nothing (other than when 
/dev/random
is put under load), so I'm not sure about how any pool reseeding is 
coming from
external hwrng unless being forced.  I have verified this with 
dumpcap/wireshark.
Even with the tickler running I would prefer to see a higher freq. of 
OneRNG
entropy injected.  I think this should be fixed but even if it was fixed 
for
kernels <5.6 would that fix work on 5.6+?
> 
> I haven't looked at the new driver yet - is /dev/random still 
> writeable?
> (adding entropy into the CSPRNG)

I haven't seen anything to contradict what Jim wrote below about the 
pool still
being writeable, but I don't know if writing entropy data directly to 
the pool
actually gets mixed or if one must use rngd.  Doesn't rngd qualify the 
entropy
that is mixed from an external source?

>                              ... if the existing mechanism that 
> provides back
> pressure and fetches more entropy through RNGD when the kernel entropy
> estimate drops is now borked then we can probably stop using RNGD and 
> just
> start writing data to /dev/random at a fixed rate (essentially 
> equivalent to
> urandom_min_reseed_secs but for everything)
> 

Since 5.6 removes estimation of the pool size, there is no other way 
other
than to inject/mix external entropy at some rate.

Fixed rate entropy injection would work but a variable rate proportional 
to
entropy read rate plus ceiling and floor would be better.  A rough 
approximation
of the entropy read rate would work and I don't see how it could 
negatively
impact security since the state would still be black box.  I don't think 
this
is doable right now.  As far as I know you can see what processes are 
accessing
the entropy pools but you can't see how much entropy they are reading.  
This
would probably require a patch.