On Sep 26, 7:40pm, Christos Zoulas wrote:
} In article <390f4c81-bf1c-443f-f7a9-a379c46b7...@m00nbsd.net>,
} Maxime Villard <m...@m00nbsd.net> 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
Or, did you want an additional sysctl that is specific to compat
modules. Then there is the question of whether it includes
COMPAT_NETBSDxx? I know the discussion has focused on COMPAT_LINUX,
but there are plenty of other COMPAT_*.
There is also my earlier message about only being able to load
modules at secure level 0. This makes them more difficult to use
if you don't have options INSECURE. With the new kernel side
graphics card drivers, we should looking at removing that by default.
}-- End of excerpt from Christos Zoulas
