kern/57552: fileassoc(9) causes rm to take kernel lock even when never used

[campbell+netbsd%mumble.net@localhost]

>Number:         57552
>Category:       kern
>Synopsis:       fileassoc(9) causes rm to take kernel lock even when never used
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jul 30 15:40:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, 8, &c.
>Organization:
The NetBSD Fileassociation
>Environment:
burning just a tiny bit faster with the energy wasted on the kernel lock here
>Description:
If veriexec is compiled into the kernel, then fileassoc_domain is initialized via main -> veriexec_init -> fileassoc_register -> RUN_ONCE(..., fileassoc_init) -> fileassoc_init.

https://nxr.netbsd.org/xref/src/sys/kern/init_main.c?r=1.542#594
https://nxr.netbsd.org/xref/src/sys/kern/kern_veriexec.c?r=1.27#334
https://nxr.netbsd.org/xref/src/sys/kern/kern_fileassoc.c?r=1.36#187
https://nxr.netbsd.org/xref/src/sys/kern/kern_fileassoc.c?r=1.36#171

In this case, every rm-like syscall goes through do_sys_unlinkat which calls fileassoc_file_delete which finds fileassoc_domain nonnull and therefore takes a pass through the kernel lock, even if nothing else in the system has ever used fileassoc:

https://nxr.netbsd.org/xref/src/sys/kern/vfs_syscalls.c?r=1.560#2911
https://nxr.netbsd.org/xref/src/sys/kern/kern_fileassoc.c?r=1.36#513

(fileassoc and veriexec locking -- and probably vfs semantics -- is also broken to the point that it is hard to imagine these can actually provide meaningful security; e.g., https://gnats.netbsd.org/35351 and https://gnats.netbsd.org/41251, and what happens if VOP_REMOVE fails, say because of a permissions error?)

(It's also not clear vp->v_mount is safe inside fileassoc_file_lookup.)
>How-To-Repeat:
dtrace use of the kernel lock in ordinary system usage without veriexec.
>Fix:
Yes, please!

Maybe just use a global thmap (lazily initialized) for these associations instead of fussing around with specificdata keys and wotsits.  Won't fix any fundamental locking problems of the API but it might help avoid touching the kernel lock.