ithread: don't collect entropy in swi_sched()

[glebius]

Summary

The entropy will be collected in intr_event_schedule_thread() for event
handlers that are marked as entropy sources.

[kib]

It seems that RANDOM_SWI becomes unused after the change.

[glebius]

I'm not an expert, but my gut feeling says that a software interrupt isn't a good source of entropy in the first place. Should I remove RANDOM_SWI as well?

Looking further into this. On one hand swi_add() requires the registered swi doesn't have INTR_ENTROPY flag. This prevent entropy collection by intr_event_schedule_thread() from swis. On the other hand swi_sched() explicitly collects it. Seems controversial.

[kib]

It seems to just happens in 3e5da754456bcfc8d11158ee.

[markj]

Note that the RANDOM_* constants are implicitly part of the user ABI via the kern.random.harvest.mask sysctl. So if RANDOM_SWI is retired, we should avoid reusing the value.

[jhb]

The actual commit that added this was

commit d95dca1d08c9d96911372a33d6791e158265d13c
Author: John Baldwin <[e-mail]>
Date:   Tue Sep 25 14:55:46 2012 +0000

    Add optional entropy harvesting for software interrupts in swi_sched()
    as controlled by kern.random.sys.harvest.swi.  SWI harvesting feeds into
    the interrupt FIFO and each event is estimated as providing a single bit of
    entropy.
    
    Reviewed by:    markm, obrien
    MFC after:      2 weeks

Notes:
    svn path=/head/; revision=240921

I'm trying to find the rationale for adding this, so far I've found a (long) thread in on security@ in Sep 2012 (so around the time of this commit) that considered harvesting entropy from device attach times, but I'm not finding a thread for this. Nevertheless, the decisions on which sources to use for entropy and the default settings, etc. have generally been managed by csprng and they should be the ones to review decisions on which entropy sources to keep/not keep. At the very least you'd probably want to start by disabling it by default? Are you seeing this show up as a performance bottleneck in a measurement or is this more of a "looks odd when I read the code" thing?

[cem]

I think 1 bit per byte sources are sort of frowned upon nowadays, even if they don't really hurt Fortuna etc. No objection, for whatever it's worth.

[jhb]

Please do correct the commit log to be something more like "random: Don't collect entropy when scheduling software interrupt handlers" and then maybe a summary of Conrad's comment in the body saying that it doesn't provide very much entropy in practice.

[cem]

In D58829#1355386, @jhb wrote:

Please do correct the commit log to be something more like "random: Don't collect entropy when scheduling software interrupt handlers" and then maybe a summary of Conrad's comment in the body saying that it doesn't provide very much entropy in practice.

Maybe also point at D12610 / discussion of min entropy in the 2017 W. Dean Freeman vBSDcon talk https://people.freebsd.org/~jmg/vbsdcon_2017_ddfreebsdrng_slides.pdf

[ngie]

It might be a good idea to check with the Juniper folks as well (@obrien , @sjg)--if nothing else, as a heads up on this change. It could require additional scrutiny recertifying JunOS for NIST SP800-90B compliance.

Dell [PowerScale] went another direction using the jitterentropy library -- which I didn't commit to base after the side-discussion I had with @cem around the quality of the generated entropy and after analyzing the scaling overhead associated with each process that links libcrypto [1]

1. An extra thread is setup per-process to "generate noise" instead of having the entropy be generated systemwide. The JE author has a lot of side-projects for generating entropy noise in Linux, but the JE library is the only means really made available in a POSIX OS compliant manner by the JE author.