Proposal: Disable autoload of compat_xyz modules

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

Many of our binary compatibility modules are notoriously ridden with
bugs.  We currently have no way to automatically test them.  Some of
them are maintained; some of them are not.  The value of having NetBSD
automatically try to execute a SCO Unix binary, for example, seems
rather weak compared to the security risk of the attack surface.

So I propose to exclude all non-NetBSD, non-ELF/a.out compat modules
from autoloading by exec, and remove them from all GENERIC kernels.
Under this proposal, if you want them in your system, you can add them
to your kernel config or modload them explicitly.

This is a compromise between preserving the functionality and reducing
attack surface for what I hypothesize are a majority of users who do
not use it.  Under this proposal, the code will remain, and still be
built, and still be usable -- it will just not be enabled by default.
In particular, I'm not questioning the value of having (e.g.) Linux
binary compatibility support; it'll just be one modload away.

The modules and kernel options that are currently autoloaded by exec
and/or included in some GENERIC kernels that I propose to disable by
default are:

compat_freebsd
compat_ibcs2
compat_linux
compat_linux32
compat_ndis
compat_osf1
compat_sunos
compat_sunos32
compat_svr4
compat_svr4_32
compat_ultrix
exec_coff
exec_ecoff

Do you, or does anyone you know, rely on any of these modules?  Can
you argue that they *should* be autoloaded by default for the typical
user, and not enabled explicitly by operators who know they need them?

Can you tell me who maintains them, or if nobody does, can you
volunteer to maintain them -- by auditing them, by testing them if
someone else applies a security fix, by writing automatic tests with
sample binaries that we can put into atf?

I'm not asking to delete the code -- only whether it should be enabled
by default.  If I hear nothing in one week, then I will disable these
by default, and a week later, I will request pullups to netbsd-7 and
netbsd-8.


P.S.  The old-NetBSD, a.out, and 32-bit compat modules may be broken
too, and are probably not automatically tested either, but are more
likely to be manually tested and I'm not addressing them right now.
These are:

compat (i.e., old-NetBSD binary compat)
compat_aoutm68k
compat_netbsd32
exec_aout
exec_elf32
exec_elf64
exec_script