An Idea for Improving Linux Kernel Module Compatibility

512KB — Fri, 16 Oct 2026 08:52:16 +0000

Background

Anyone who has worked on Linux kernel development probably knows that starting with Linux 5.7, kallsyms_lookup_name() was no longer exported to prevent third-party modules from bypassing EXPORT_SYMBOL restrictions and accessing internal kernel functions.

Meanwhile, eBPF has continued to grow, but it still can't replace traditional kernel modules in every scenario, such as hardware driver development or certain security features that need to suspend kernel operations while waiting for a decision from user space.

This makes me wonder: if traditional kernel modules have compatibility issues, why can't we improve their compatibility mechanisms while continuing to develop eBPF?

On Misuse

Removing the export of kallsyms_lookup_name() certainly makes it harder for third-party modules to access internal symbols. But those who genuinely need these symbols can still find other ways to locate them.

As a result, misuse hasn't been completely prevented, while operations that could previously be done directly through an exported function now require more complicated workarounds.

For example, this change in Linux 5.7 affected LTTng.

I understand why kernel maintainers don't want third-party drivers to depend on internal implementation details. But removing a lookup interface doesn't make the need for it disappear.

Of course, being able to find a symbol doesn't mean you should be free to call it however you like. These two points aren't contradictory.

On Compatibility Complexity

eBPF has certainly solved some problems, but it cannot cover every use case.

For out-of-tree driver developers, even if their projects are completely open source, they still have to deal with symbol CRC mismatches, changes to structure layouts, removed interfaces, and differences between Linux distributions.

Although we now have two kernel extension mechanisms with different capabilities, we still lack a general-purpose solution for cross-version compatibility of traditional out-of-tree modules.

Another Approach

If kernel maintainers don't want to guarantee long-term stability for every internal symbol, could we instead maintain just a minimal stable module loading interface and a more capable symbol lookup API?

For example, when a driver looks up a symbol, the kernel could return additional metadata:

Symbol address
Symbol type and ABI version information
Function prototype or type hash
The module that owns the symbol and its lifetime information
Export status, access restrictions, and supported capabilities

For internal symbols that aren't exported, we could also consider more fine-grained access controls instead of simply denying access altogether.

As much type information as possible could be generated automatically by build tools, while behavioral compatibility would require explicit versioning rules to reduce the maintenance burden.

How to use that information would then be up to the driver developers. This way, the kernel would still not need to guarantee long-term ABI stability for the vast majority of its internal functions.

Cost Considerations

Of course, this design would come with costs.

The stable core interfaces would need to be maintained, and a version number alone cannot capture every change in a symbol's behavior. Defining access permissions for unexported internal symbols would also be a challenge.

But these issues are at least worth discussing, rather than treating "the kernel doesn't guarantee a stable ABI" as the end of the conversation.

If a core interface eventually needs a breaking change, a new version could be introduced, with a reasonable support period for the old one.

Red Hat and Android GKI have already implemented stable kernel ABIs within certain limits. This shows that maintaining ABI stability is possible under the right conditions.

Conclusion

If we can let the kernel evolve freely while allowing external drivers to detect and adapt to changes on their own, why not give it a try?

PS

Note: This article was originally written by me in Chinese. I used AI to help translate it into English, but the ideas and opinions are entirely my own.
Original Chinese version: Linux 内核模块为什么不能自己解决兼容性问题？

DEV Community: 512KB