Re: compat code being included in non-compat kernels?

[Maxime Villard <max%m00nbsd.net@localhost>]

Le 05/03/2018 à 11:02, Paul Goyette a écrit :
> I've notice an anomaly on which I hope someone can shed some light...
>
> For some time now I've noticed that periodically something triggers the
> "load all the exec modules on the off chance that it will let me exec
> this image" - the code is function exec_autoload() in kern_exec.c (and
> called from execve_loadvm() ).
>
> I haven't found the trigger yet, but that's not the problem about which
> I'm currently concerned.
>
> Today's concern is that attempts to load the compat module fail because
> all of its symbols are _already_ included in the current kernel, even
> though that kernel was compiled with _no_ COMPAT options of any sort!
> It seems that everything is in included in the kernel's libcompat.o
> which means everything is in the kernel.
>
> Well, almost everything!  The one piece of compat that seems to be
> absent is the definition of the module itself, the MODULE(..., compat,
> ...) which resides in src/sys/compat/common/compat_mod.c
>
> As a result we have a fundamentally broken modularity system where
> the compat_netbsd32 cannot be loaded because its required compat cannot
> load because its contents are already in the kernel, unregistered!
>
> I'm not sure when this started, but it's been happening for at least
> several weeks, and probably a few months.

It happens because I changed libcompat, it is now built as an object and not
as a library, which fixes a number of issues.

libcompat needs to be removed, and we must use a files.common to build its
code depending on a particular kernel option.

I had prepared such a change [1]; each COMPAT_ option depends on COMPAT_NETBSD,
and COMPAT_NETBSD builds the common code. Then if you build a kernel without
any COMPAT_ option, COMPAT_NETBSD doesn't get compiled, and you can modload
from the filesystem.

Maxime

[1] http://m00nbsd.net/garbage/compat/