This patch series implements a mechanism for scalable exported symbol
flags using a separate section called __kflagstab. The series introduces
__kflagstab support, removes *_gpl sections in favor of a GPL flag,
simplifies symbol resolution during module loading, and adds symbol
import protection.

Thank you Petr Pavlu for their valuable feedback.

---
Changes from v1:
- added a check to ensure __kflagstab is present
- added warnings for the obsolete *_gpl sections
- moved protected symbol check before ref_module() call
- moved protected symbol check failure warning to issue detection point

v1:
https://lore.kernel.org/all/20250829105418.3053274-1-sidnayyar@google.com/

Siddharth Nayyar (10):
  define kernel symbol flags
  linker: add kflagstab section to vmlinux and modules
  modpost: create entries for kflagstab
  module loader: use kflagstab instead of *_gpl sections
  modpost: put all exported symbols in ksymtab section
  module loader: remove references of *_gpl sections
  linker: remove *_gpl sections from vmlinux and modules
  remove references to *_gpl sections in documentation
  modpost: add symbol import protection flag to kflagstab
  module loader: enforce symbol import protection

 Documentation/kbuild/modules.rst  |  11 +--
 include/asm-generic/vmlinux.lds.h |  21 ++----
 include/linux/export-internal.h   |  28 +++++---
 include/linux/module.h            |   4 +-
 include/linux/module_symbol.h     |   6 ++
 kernel/module/internal.h          |   5 +-
 kernel/module/main.c              | 112 +++++++++++++++---------------
 scripts/mod/modpost.c             |  27 +++++--
 scripts/module.lds.S              |   3 +-
 9 files changed, 120 insertions(+), 97 deletions(-)

-- 
2.51.0.740.g6adb054d12-goog

Siddharth Nayyar <sidnayyar@google.com> writes:

> This patch series implements a mechanism for scalable exported symbol
> flags using a separate section called __kflagstab. The series introduces
> __kflagstab support, removes *_gpl sections in favor of a GPL flag,
> simplifies symbol resolution during module loading, and adds symbol
> import protection.

This caught my eye in passing ... some questions ...

The import protection would appear to be the real point of this work?
But it seems that you have kind of buried it; why not describe what you
are trying to do here and how it will be used?

I ask "how it will be used" since you don't provide any way to actually
mark exports with this new flag.  What is the intended usage here?

If I understand things correctly, applying this series will immediately
result in the inability to load any previously built modules, right?
That will create a sort of flag day for anybody with out-of-tree modules
that some may well see as a regression.  Is that really the intent?

Thanks,

jon

On Mon, Oct 13, 2025 at 8:02PM Jonathan Corbet <corbet@lwn.net> wrote:
> Siddharth Nayyar <sidnayyar@google.com> writes:
> > This patch series implements a mechanism for scalable exported symbol
> > flags using a separate section called __kflagstab. The series introduces
> > __kflagstab support, removes *_gpl sections in favor of a GPL flag,
> > simplifies symbol resolution during module loading, and adds symbol
> > import protection.
>
> This caught my eye in passing ... some questions ...
>
> The import protection would appear to be the real point of this work?

Yes, import protection prompted the introduction of __kflagstab. But I
would agrue that __kflagstab in its own right is an improvement to the
overall health of the module loader code, therefore can be taken even
without import protection.

> But it seems that you have kind of buried it; why not describe what you
> are trying to do here and how it will be used?

Point taken. For sake of clarity, import protection is a mechanism which
intends to restrict the use of symbols exported by vmlinux to signed
modules only, i.e. unsigned modules will be unable to use these symbols.
I will ensure this goes into the cover letter for following versions of
the patch series.

> I ask "how it will be used" since you don't provide any way to actually
> mark exports with this new flag. What is the intended usage here?

Patch 09/10 (last hunk) provides a mechanism to enable import protection
for all symbols exported by vmlinux. To summarise, modpost enables
import protection when CONFIG_UNUSED_KSYMS_WHITELIST is set. This
results in all symbols except for the ones mentioned in the whitelist to
be protected from being imported by out-of-tree modules. In other words,
out-of-tree modules can only use symbols mentioned in
CONFIG_UNUSED_KSYMS_WHITELIST, when the config option is set.

I realise I should have documented this behaviour, both in the cover
letter as well as in kernel documentation. I will do so in the following
version of the patch series.

Please share any feedback on the mechnism to enable the mechanism. In my
opinion, CONFIG_UNUSED_KSYMS_WHITELIST has a complementary goal to
import protection and therefore I felt like using the option to enable
import protection. In case this seems to convoluted, I am okay with
introducing an explicit option to enable import protection.

> If I understand things correctly, applying this series will immediately
> result in the inability to load any previously built modules, right?
> That will create a sort of flag day for anybody with out-of-tree modules
> that some may well see as a regression. Is that really the intent?

Unfortunately this series will break all modules which export symbols
since older versions of such modules will not have the kflagstab
section.

Out-of-tree modules which do not export symbols of their own will only
fail to load in case the CONFIG_UNUSED_KSYMS_WHITELIST is set and the
symbols which these modules consume are not present in the whitelist.

Regards,
Siddharth Nayyar

On 10/21/25 12:43 AM, Siddharth Nayyar wrote:
> On Mon, Oct 13, 2025 at 8:02PM Jonathan Corbet <corbet@lwn.net> wrote:
>> I ask "how it will be used" since you don't provide any way to actually
>> mark exports with this new flag. What is the intended usage here?
> 
> Patch 09/10 (last hunk) provides a mechanism to enable import protection
> for all symbols exported by vmlinux. To summarise, modpost enables
> import protection when CONFIG_UNUSED_KSYMS_WHITELIST is set. This
> results in all symbols except for the ones mentioned in the whitelist to
> be protected from being imported by out-of-tree modules. In other words,
> out-of-tree modules can only use symbols mentioned in
> CONFIG_UNUSED_KSYMS_WHITELIST, when the config option is set.
> 
> I realise I should have documented this behaviour, both in the cover
> letter as well as in kernel documentation. I will do so in the following
> version of the patch series.
> 
> Please share any feedback on the mechnism to enable the mechanism. In my
> opinion, CONFIG_UNUSED_KSYMS_WHITELIST has a complementary goal to
> import protection and therefore I felt like using the option to enable
> import protection. In case this seems to convoluted, I am okay with
> introducing an explicit option to enable import protection.

CONFIG_UNUSED_KSYMS_WHITELIST was originally added in commit
1518c633df78 ("kbuild: allow symbol whitelisting with
TRIM_UNUSED_KSYMS"), specifically for Android. Looking at configs of
several distributions [1], it appears that it has only been used by
Android so far. This means it is likely acceptable to protect the
whitelist symbols in this manner.

On the other hand, I think what is protected (all exported symbols or
CONFIG_UNUSED_KSYMS_WHITELIST) and how it is protected
(KSYM_FLAG_PROTECTED) are two different things, so it might be cleaner
to keep them separate.

> 
>> If I understand things correctly, applying this series will immediately
>> result in the inability to load any previously built modules, right?
>> That will create a sort of flag day for anybody with out-of-tree modules
>> that some may well see as a regression. Is that really the intent?
> 
> Unfortunately this series will break all modules which export symbols
> since older versions of such modules will not have the kflagstab
> section.

I would add that out-of-tree modules are typically leaves that don't
export any symbols. This means it should still be possible to load such
modules on an updated kernel.

A problem occurs when out-of-tree support is split into multiple
modules, where one module exports data for another. Some drivers can be
split in such a way. For example, a NIC driver might be divided into
core, Ethernet and InfiniBand modules, where the core provides exports
for the latter modules.

In such a case, the kernel will ignore the __ksymtab_gpl section in the
first module and issue a warning about it (patch #6). Eventually, when
the second module is attempted to be inserted, the load operation will
result in an error due to an unresolved import.

In practice, I believe this series should have limited impact. Stable
trees and distributions that care about kABI stability should not
backport it. In contrast, people who follow master releases typically
don't use out-of-tree modules, or they know how to deal with updating
them. In this case, only recompilation is needed, which is less
impactful than when an API changes and the actual module code needs to
be updated.

In the past, there were already breaking changes to the format of the
exported data, notably in commit 7290d5809571 ("module: use relative
references for __ksymtab entries") and 8651ec01daed ("module: add
support for symbol namespaces."). As far as I'm aware, these changes
didn't cause significant trouble, even though they actually resulted in
silent breakages of old modules with exports.

> 
> Out-of-tree modules which do not export symbols of their own will only
> fail to load in case the CONFIG_UNUSED_KSYMS_WHITELIST is set and the
> symbols which these modules consume are not present in the whitelist.

[1] https://oracle.github.io/kconfigs/?config=UTS_RELEASE&config=UNUSED_KSYMS_WHITELIST

-- 
Thanks,
Petr