Alternative to the GPL find_symbol method in Linux kernel module

Question

I have a proprietary Linux module which might be loaded before or after a second proprietary module that contain the function foo.

I would like my first module, when being configured dynamically, to lookup for the second's module symbol foo, and if found to call it.

The general idea (in loose syntax) is this:

/* check if the module/symbol can be found */    
module, foo_cb = lookup_for_a_symbol("foo");

if (foo_cb && module) {
    /* increment the refcnt to make sure the module will not be unloaded */
    module_try_get(module);

    foo_cb(my_params);

    /* release the module */ 
    module_put(module);
}

I found a function in module.c that does something like this called find_symbol, however it is GPL.

Any non-GPL alternative for dynamic symbol lookup ?

Thanks.

A good discussion is at [Kernel symbol marked with “T” in /proc/kallsyms is not exported](https://stackoverflow.com/q/32965535/608639). It introduces `kallsyms_lookup_name` and `kallsyms_lookup` but they are probably GPL, too. Another related one is [Unknown symbol flush_tlb_all (err 0)](https://stackoverflow.com/q/52082603/608639). — jww, Oct 09 '18 at 13:27
It's possible, from userspace to parse /proc/kallsyms, get the symbol and the module, and send the addresses to the module. but this seems hacky, and error prone, if for example, the module was removed since — Itay Marom, Oct 09 '18 at 13:37
Create a GPL helper module, which exports a function (using EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL) to look up your symbol, which can be then used in your module with proprietary licence — Ctx, Oct 09 '18 at 13:38
That's kind of clever @Ctx. It seems like that should run afoul of some versions of GPL. I believe that is what kind of happened with the situation at [Being honest with MODULE_LICENSE](https://lwn.net/Articles/82305/) on LWN, but it was deemed OK. The symbol helper module does seem to run afoul of the *"... it is not an attempt to get around the kernel's simplistic access control mechanism [for a symbol]"* discussed in the article, but I am not sure what happens next. — jww, Oct 09 '18 at 13:45
@jww Yes, I think it might be problematik when re-exporting functions as a whole in such "licence-adapter-modules", but probably doing such a narrow task as looking up a single symbol isn't really infringing the licence. But IANAL of course — Ctx, Oct 09 '18 at 13:48
@Ctx but, we now need to make sure that the GPL proxy module is loaded..isn't this moving the same problem to a different place ? — Itay Marom, Oct 09 '18 at 13:55
@ItayMarom Hm, not really... You just install both modules, depmod and modprobe will take care of loading it automatically — Ctx, Oct 09 '18 at 13:56
@ctx but if I can make sure it will always be loaded at startup, it can provide dynamic lookup...good idea — Itay Marom, Oct 09 '18 at 13:57
I'm prepared to argue that a kernel image dump is GPL even if the original modules weren't. — Joshua, Oct 09 '18 at 14:33

score 0 · Answer 1 · answered Oct 09 '18 at 14:10

But your module does not export GPL symbols, so this should not be a problem. The only problem is if you want to be able to load proprietary module bar without loading foo.

Module foo should use EXPORT_SYMBOL() to export anything that will be used by bar.

If you need conditional dynamic linking, then add a third module to do this, which calls bar with the symbol from foo and use EXPORT_SYMBOL() in both foo and bar to make the necessary symbols available to module foobar.

score 0 · Answer 2 · answered Dec 09 '19 at 09:09

Sorry I know it is a relatively old question, but I recently had the same need and I used a pretty obvious solution without creating a GPL helper module that nobody mentioned here, so I think it is worth mentioning.

scnprintf is non GPL, and it supports %pf or %pF format that does the symbol resolution you need. See printk formats

Alternative to the GPL *find_symbol* method in Linux kernel module

2 Answers2

Alternative to the GPL find_symbol method in Linux kernel module