PR/58575 CVS commit: [netbsd-10] src/sys/crypto/cprng_fast

["Martin Husemann" <martin%netbsd.org@localhost>]

The following reply was made to PR kern/58575; it has been noted by GNATS.

From: "Martin Husemann" <martin%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/58575 CVS commit: [netbsd-10] src/sys/crypto/cprng_fast
Date: Sat, 26 Oct 2024 15:59:53 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sat Oct 26 15:59:53 UTC 2024
 
 Modified Files:
 	src/sys/crypto/cprng_fast [netbsd-10]: cprng_fast.c
 
 Log Message:
 Pull up following revision(s) (requested by riastradh in ticket #990):
 
 	sys/crypto/cprng_fast/cprng_fast.c: revision 1.20
 
 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.18.4.1 -r1.18.4.2 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.