Re: Proposal, again: Disable autoload of compat_xyz modules

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

In article <201909262031.x8QKVnpV021333%server.cornerstoneservice.ca@localhost>,
John Nemeth  <jnemeth%cue.bc.ca@localhost> wrote:
>On Sep 26,  7:40pm, Christos Zoulas wrote:
>} 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)
>
>     You mean this (first line):
>
>i386devel: {31} sysctl kern.module
>kern.module.autoload = 0
>kern.module.verbose = 0
>kern.module.path = /stand/amd64-xen/8.99.26/modules
>kern.module.autotime = 10

Perhaps:

kern.module.autoload.disable = linux,linux32

christos