lib/59148: arc4random calls malloc so it can't be used in an ELF constructor

[campbell+netbsd%mumble.net@localhost]

>Number:         59148
>Category:       lib
>Synopsis:       arc4random calls malloc so it can't be used in an ELF constructor
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 06 14:40:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10
>Organization:
The Arc4BSD Constrepochtor
>Environment:
>Description:
For PR kern/58632: getentropy(2) and arc4random(3) do not reseed on VM fork <https://gnats.NetBSD.org/58632>, we exposed the entropy epoch to userland and taught arc4random(3) to query it.

Unfortunately, this had the side effect of creating a path from arc4random(3) to malloc(3), which means it can't be used in ELF constructors, ifunc selectors, and similar contexts.  The path goes via sysctlnametomib(3), which uses malloc(3) to handle unbounded memory allocation, as required by the sysctl(2) interface -- an unfortunate requirement, chronicled in PR kern/59147: sysctl: bounded-memory lookups by name <https://gnats.NetBSD.org/59147>.  And kern.* is fairly hefty to list, requiring tens of kilobytes of struct sysctlnodes.
>How-To-Repeat:
call arc4random in an elf constructor and roll the dice to see if sparks fly (not guaranteed, you might get lucky and malloc initialization might happen first)
>Fix:
Checking the entropy epoch, and reseeding if it has changed, is an important security property, so simply reverting the changes for PR 58632 is a nonstarter.

Perhaps, until we either resolve PR kern/59147 by implementing a path for bounded-memory lookup by name, or implement vDSO and expose the entropy epoch through that, we should use an ELF constructor for arc4random to resolve the sysctl when the stack is nearly empty so eating tens of kilobytes out of it isn't that big a deal, like we did for PR port-arm/59147: libc constructors on arm use malloc <https://gnats.NetBSD.org/59147>.

Or, we could just statically assign KERN_ENTROPY and KERN_ENTROPY_EPOCH numbers and skip the runtime name resolution altogether.