Re: Proposal, again: Disable autoload of compat_xyz modules

[christos%astron.com@localhost (Christos Zoulas)]

In article <390f4c81-bf1c-443f-f7a9-a379c46b767f%m00nbsd.net@localhost>,
Maxime Villard  <max%m00nbsd.net@localhost> wrote:
>I recently made a big set of changes to fix many bugs and vulnerabilities in
>compat_linux and compat_linux32, the majority of which have a security impact
>bigger than the Intel CPU bugs we hear about so much. These compat layers are
>enabled by default, so everybody is affected.
>
>Secteam is in a state where no one is willing to pull up all the changes to
>the stable branches, because of the effort. No one is willing to write a
>security advisory either. When I say "no one", it includes me.
>
>The proposal and discussion held in this 2017 thread still hold and are
>unchanged two years later:
>
>	https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html
>
>The compat layers are largely untested, often broken, and are a security risk
>for everybody. Keeping them enabled for the <1% users interested means keeping
>vulnerabilities for the >99% who don't use these features.
>
>In the conversation above, we hit the problem that there was cross-dependency
>among compat modules, and we couldn't selectively disable specific layers.
>Today this is possible thanks to pgoyette's work. That is, it is possible to
>comment out "options COMPAT_LINUX" from GENERIC, and have a compat_linux.kmod
>which will modload correctly and be able to run Linux binaries out of the box.
>Under this scheme, the feature would be only one root command away from being
>enabled in the kernel.
>
>Therefore, I am making today the same proposal as Taylor in 2017, because the
>problem is still there exactly as-is and we just hit it again; the solution
>however is more straightforward.

I propose something very slightly different that can preserve the current
functionality with user action:

1. Remove them from standard kernels in architectures where modules are
   supported. Users can add them back or just use modules.
2. Disable autoloading, but provide a sysctl to enable autoloading
   (1 global sysctl for all compat modules). Users can change the default
   in /etc/sysctl.conf (adds sysctl to the proposal)

christos