Le 10/09/2017 à 12:24, Paul Goyette a écrit :On Sun, 10 Sep 2017, Maxime Villard wrote:
Re-thinking about this again, it seems to me we could simply add a flags
field in modinfo_t, with a bit that says "if this module is builtin, then
don't load it". To use compat_xyz, you'll have to type modload, and the
kernel will load the module from the builtin list.
Something like [1] (from memory, not tested at all). Obviously this patch
is not complete, since we need to update each MODULE().
While it is clear that it does not solve the cross-dependency issue we're
having, it does reduce the attack surface almost as much as if the module
was not builtin, with very little effort. Cheap, but relevant.
[1] http://m00nbsd.net/garbage/module/noload.diff
Well, probably not quite what you wanted, but if a module is built-in
you can disable it by using modunload(8). Any built-in module which has
been disabled in this manner needs to be explicitly reload manually, and
you'll need to additionally specify the -f option to modload(8).
I know.Perhaps /etc/rc.d/modules can be updated to have both a load and an
unload phase, with appropriate syntax for the associated config file.
Thought about this too, but it seemed bizarre to me to have the kernel loadmodules, then rc.d/modules unload them, and then the user reload them.This would be a lot cleaner IMHO than updating individual modules.
I believe per-module flags can be useful in the future, and not just in thenoload case; a module could want to tell the kernel how it wants to be loaded.
I think "how a module should be loaded" should be left to the sysadmins discretion, not the module itself.
Besides that, I don't like the whole idea of built-in modules not being activated by default, after all that is how it has been for many releases.
|