On Mon, Oct 13, 2025 at 8:02PM Jonathan Corbet <[email protected]> wrote: > Siddharth Nayyar <[email protected]> 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
