Re: Proposal, again: Disable autoload of compat_xyz modules

[Greg Troxel <gdt%lexort.com@localhost>]

christos%astron.com@localhost (Christos Zoulas) writes:

> 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)

I am assuming that we are talking about disabling autoloading of a
number of compat modules that are some combination of believed likely to
have security bugs and not used extensively, and this includes compat
for foreign OS, but does not, at least for now, include compat for older
NetBSD.

This situation is basically a balancing act of the needs/benefits
somehow aggregated (I will avoid "averaged") over all users.   It seems
pretty unclear how to evaluate that in total.  But, it does seem like
your single-sysctl proposal means:

  people who like compat being autoloaded can add one line in
  sysctl.conf and be back where they were

  people who want specific modules can load them and not enable the
  general sysctl

  people who don't know about any of this who try to run Linux binaries
  will lose, and presumably there'd be a line in dmesg that says which
  module failed to autoload, like
    policy blocked autoloading compat_linux module; see compat_linux(8)
  which would then explain.

I'm also assuming this is being talked about for HEAD and hence 10, and
not 9.

Overall, this seems like a reasonable compromise among conflicting
goals.

If older NetBSD compat were included, I'd want to see a separate sysctl,
default-on for now.  (My guess is that wanting to disable that is a
fairly extreme position, at least these days.)