Module Name: src
Committed By: riastradh
Date: Tue Oct 15 17:34:06 UTC 2024
Modified Files:
src/sys/crypto/cprng_fast: cprng_fast.c
Log Message:
Revert cprng_fast(9) to seed and reseed asynchronously in softint.
This reverts sys/crypto/cprng_fast/cprng_fast.c revisions 1.17-1.19.
I thought we had eliminated all paths into cprng_fast(9) from hard
interrupt context, which would allow us to call into cprng_strong(9)
and entropy(9) to synchronously reseed whenever needed -- this would
improve security over netbsd-9 for the first query to cprng_intr(9)
on each CPU.
Unfortunately, I missed the calls under spin locks (which are
effectively also hard interrupt context, in that they hold up
interrupts on this CPU or interrupt handlers trying to take the lock
on other CPUs). And one such spin lock is struct ifnet::ifq_lock at
IPL_NET, which is held by if_transmit when it calls IFQ_ENQUEUE which
calls into altq(4) which sometimes does, e.g., red_addq which calls
cprng_fast32.
Until we migrate ifq_lock to IPL_SOFTNET (which is potentially
feasible, because most of the network stack runs in softint now, but
it requires a lot of auditing and maybe changes to lots of drivers),
we'll have to make sure cprng_fast(9) doesn't try to take an adaptive
lock.
And the simplest way to ensure that is to just revert back to the
netbsd-9 semantics of asynchronously reseeding in softint, at the
cost of a potential security weakness. I don't expect this
regression to be permanent -- we just can't restore the change as is
until we deal with ifq_lock.
1.19 cprng_fast(9): Drop and retake percpu reference across cprng_strong.
1.18 cprng_fast(9): Assert not in pserialize read section.
1.17 cprng(9): cprng_fast is no longer used from interrupt context.
PR kern/58575: altq(4) takes adaptive lock while holding spin lock
To generate a diff of this commit:
cvs rdiff -u -r1.19 -r1.20 src/sys/crypto/cprng_fast/cprng_fast.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
