On Mon, Sep 22, 2025 at 12:41 PM Petr Pavlu <petr.pa...@suse.com> wrote: > This is useful information. However, I was specifically interested in > the impact of having the new flags field present as part of __ksymtab > (kernel_symbol), compared to keeping it in a separate section. Sorry for > not being clear. > > I ran a small test to get a better understanding of the different sizes. > I used v6.17-rc6 together with the openSUSE x86_64 config [1], which is > fairly large. The resulting vmlinux.bin (no debuginfo) had an on-disk > size of 58 MiB, and included 5937 + 6589 (GPL-only) exported symbols. > > The following table summarizes my measurements and calculations > regarding the sizes of all sections related to exported symbols: > > | HAVE_ARCH_PREL32_RELOCATIONS | > !HAVE_ARCH_PREL32_RELOCATIONS > Section | Base [B] | Ext. [B] | Sep. [B] | Base [B] | Ext. [B] > | Sep. [B] > ---------------------------------------------------------------------------------------- > __ksymtab | 71244 | 200416 | 150312 | 142488 | 400832 > | 300624 > __ksymtab_gpl | 79068 | NA | NA | 158136 | NA > | NA > __kcrctab | 23748 | 50104 | 50104 | 23748 | 50104 > | 50104 > __kcrctab_gpl | 26356 | NA | NA | 26356 | NA > | NA > __ksymtab_strings | 253628 | 253628 | 253628 | 253628 | 253628 > | 253628 > __kflagstab | NA | NA | 12526 | NA | NA > | 12526 > ---------------------------------------------------------------------------------------- > Total | 454044 | 504148 | 466570 | 604356 | 704564 > | 616882 > Increase to base [%] | NA | 11.0 | 2.8 | NA | 16.6 > | 2.1 > > The column "HAVE_ARCH_PREL32_RELOCATIONS -> Base" contains the numbers > that I measured. The rest of the values are calculated. The "Ext." > column represents the variant of extending __ksymtab, and the "Sep." > column represents the variant of having a separate __kflagstab. With > HAVE_ARCH_PREL32_RELOCATIONS, each kernel_symbol is 12 B in size and is > extended to 16 B. With !HAVE_ARCH_PREL32_RELOCATIONS, it is 24 B, > extended to 32 B. Note that this does not include the metadata needed to > relocate __ksymtab*, which is freed after the initial processing. > > The base export data in this case totals 0.43 MiB. About 50% is used for > storing the names of exported symbols. > > Adding __kflagstab as a separate section has a negligible impact, as > expected. When extending __ksymtab (kernel_symbol) instead, the worst > case with !HAVE_ARCH_PREL32_RELOCATIONS increases the export data size > by 16.6%. > > Based on the above, I think introducing __kflagstab makes senses, as the > added complexity is minimal, although I feel we could probably also get > away with extending kernel_symbol.
This investigation is very informative, thank you for sharing your findings. I am in agreement with your conclusions. > This seems to answer why the in-tree flag is not sufficient for you. > However, I also suggested an alternative that the symbol protection > could be determined by whether the module is signed by a key from the > .builtin_trusted_keys keyring, as opposed to being signed by another key > reachable from the .secondary_trusted_keys keyring or being completely > unsigned. > > Distributions can require that external modules be signed and allow > additional keys to be added as Machine Owner Keys, which can be made > reachable from .secondary_trusted_keys. Nonetheless, such distributions > might be still interested in limiting the number of symbols that such > external modules can use. > > I think this option is worth considering, as it could potentially make > this symbol protection useful for other distributions as well. This sounds like a great solution to enhance trust and security, apologies for missing this in the previous email. I will explore this approach, but I would like to do it in a separate series. > I'm personally ok with adding the kflagstab support. I think it > introduces minimal complexity and, as you point out, simplifies certain > aspects. Additionally, if we add it, I believe that adding the proposed > symbol protection is simple enough to be included as well, at least from > my perspective. Since we are in agreement, I would like to seek code review for this series. The code is ready for review from my side, but if you prefer I can send out a non-RFC patch series for code review. -- Thanks, Siddharth Nayyar
