Enforcement (or not) for module-specific exported symbols

Restrictions on exported symbols are driven by two core motivations, the first of which is to ensure that kernel modules are truly modular and do not access core parts of the kernel. The intent is limit the amount of damage a module can do, and to keep kernel modules from changing fundamental aspects of the kernel's operation. The other motivation is a desire to make life difficult for proprietary kernel modules by explicitly marking exports that are so fundamental to the kernel's design that any code making use of them must be a derived product of the kernel. Those symbols are unavailable to any module that does not declare a GPL-compatible license.

There have been many discussions about the proper exporting of symbols over the years; see the LWN kernel index for the history. The most recent example may be this discussion on whether the in-progress user-space stack-unwinding improvements should be made available to the out-of-tree LTTng module. These discussions do not appear to have impeded the exporting of symbols in general; there are nearly 38,000 exported symbols in the upcoming 6.16 kernel.

That kernel release will also include a new member of the EXPORT_SYMBOL() macro family:

    EXPORT_SYMBOL_GPL_FOR_MODULES(symbol, "mod1,mod2");

This macro will cause the given symbol to be exported, but only to the modules named in the second argument, and only if those modules are GPL-licensed. It is intended for use with symbols that kernel developers would strongly prefer not to export at all, but which are needed by one or more in-tree subsystems when those subsystems are built as modules. There are no users of this macro in the 6.16 kernel, but a few are waiting in the wings. The symbol exports needed for the proposed unification of kselftests and KUnit are expressed this way, for example.

The linux-next repository contains a couple of other users that are planned for merging in 6.17; included therein is the exporting of the rigorously undocumented anon_inode_make_secure_inode() exclusively for the KVM subsystem. That particular export came about as the result of a discussion following the posting, by Shivank Garg, of this patch making that function available to KVM to fix a security issue. Vlastimil Babka suggested using the new, module-specific mechanism, a suggestion that Garg quickly adopted.

Christian Brauner, having evidently learned about the new mechanism in this discussion, said that he would happily switch a number of other core filesystem-level exports to the module-specific variety, but there was one problem: some of those exports are not GPL-only, so there would need to be a version of the macro that does not impose the extra license restriction. Christoph Hellwig disagreed with the need for a non-GPL version, though, saying that any export that is limited to specific in-tree modules is, by definition, only exported to GPL-licensed code. He suggested just removing the GPL_ portion of the name of the macro, instead.

Babka pointed out one other potential difficulty, though: while the module-specific exports are intended for in-tree modules only, there is nothing in the kernel that enforces this expectation. So an evil maintainer of a proprietary module could, for example, simply name that module kvm, and anon_inode_make_secure_inode() would become available to it. To address this perceived problem, Babka posted a patch series that added enforcement of the in-tree-only rule, and also changed the name of the macro to EXPORT_SYMBOL_FOR_MODULES().

It is worth noting that this enforcement implementation, were it to be applied, would still have the potential to be circumvented in external modules. The only way that the kernel knows that a specific module is of the in-tree variety is if the module itself tells it so. Specifically, the kernel looks at the .modinfo ELF section in the binary kernel module for a line reading "intree=Y"; if that line is found, the module is deemed to be an in-tree module. If an evil developer is willing to impersonate a privileged module to gain access to a specific symbol, they probably will not be daunted by the prospect of adding a false in-tree declaration to the module as well.

In any case, though, that change ended up being dropped in the second version of the patch series. Masahiro Yamada had raised a concern with the new enforcement mechanism: some developers of in-tree modules do their work on out-of-tree versions until the work is merged. In other words, sometimes, replacing an in-tree module with an out-of-tree version using the same name is a legitimate use case. Rather than break a workflow that some developers may depend on, Babka opted to remove the enforcement mechanism entirely, leaving only the name change.

In this case, as always, the purpose of the removed change was not to create a bulletproof defense against attempts to circumvent the export mechanism. It was, instead, to make the intent of the development community clear, so that anybody engaging in such abuse has no excuses when they are caught. The existing mechanisms in the kernel should be sufficient for that purpose; anybody who is willing to bypass them would probably not have been slowed down much by the addition of another hurdle.