From: Siddharth Nayyar <sidnayyar@google.com>
To: Nathan Chancellor <nathan@kernel.org>,
Luis Chamberlain <mcgrof@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>
Cc: Nicolas Schier <nicolas.schier@linux.dev>,
Petr Pavlu <petr.pavlu@suse.com>, Arnd Bergmann <arnd@arndb.de>,
linux-kbuild@vger.kernel.org, linux-arch@vger.kernel.org,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
Siddharth Nayyar <sidnayyar@google.com>
Subject: [RFC PATCH 00/10] scalable symbol flags with __kflagstab
Date: Fri, 29 Aug 2025 10:54:08 +0000 [thread overview]
Message-ID: <20250829105418.3053274-1-sidnayyar@google.com> (raw)
Hi everyone,
This patch series proposes a new, scalable mechanism to represent
boolean flags for exported kernel symbols.
Problem Statement:
The core architectural issue with kernel symbol flags is our reliance on
splitting the main symbol table, ksymtab. To handle a single boolean
property, such as GPL-only, all exported symbols are split across two
separate tables: __ksymtab and __ksymtab_gpl.
This design forces the module loader to perform a separate search on
each of these tables for every symbol it needs, for vmlinux and for all
previously loaded modules.
This approach is fundamentally not scalable. If we were to introduce a
second flag, we would need four distinct symbol tables. For n boolean
flags, this model requires an exponential growth to 2^n tables,
dramatically increasing complexity.
Another consequence of this fragmentation is degraded performance. For
example, a binary search on the symbol table of vmlinux, that would take
only 14 comparison steps (assuming ~2^14 or 16K symbols) in a unified
table, can require up to 26 steps when spread across two tables
(assuming both tables have ~2^13 symbols). This performance penalty
worsens as more flags are added.
Proposed Solution:
This series introduces a __kflagstab section to store symbol flags in a
dedicated data structure, similar to how CRCs are handled in the
__kcrctab.
The flags for a given symbol in __kflagstab will be located at the same
index as the symbol's entry in __ksymtab and its CRC in __kcrctab. This
design decouples the flags from the symbol table itself, allowing us to
maintain a single, sorted __ksymtab. As a result, the symbol search
remains an efficient, single lookup, regardless of the number of flags
we add in the future.
The motivation for this change comes from the Android kernel, which uses
an additional symbol flag to restrict the use of certain exported
symbols by unsigned modules, thereby enhancing kernel security. This
__kflagstab can be implemented as a bitmap to efficiently manage which
symbols are available for general use versus those restricted to signed
modules only.
Patch Series Overview:
* Patch 1-8: Introduce the __kflagstab, migrate the existing GPL-only
flag to this new mechanism, and clean up the old __ksymtab_gpl
infrastructure.
* Patch 9-10: Add a "symbol import protection" flag,
which disallows unsigned modules from importing symbols marked with
this flag.
This is an RFC, and I am seeking feedback on the overall approach and
implementation before moving forward.
Thanks,
Siddharth Nayyar
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 | 6 +-
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 | 101 ++++++++++++++----------------
scripts/mod/modpost.c | 27 ++++++--
scripts/module.lds.S | 3 +-
9 files changed, 107 insertions(+), 94 deletions(-)
--
2.51.0.338.gd7d06c2dae-goog
next reply other threads:[~2025-08-29 10:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 10:54 Siddharth Nayyar [this message]
2025-08-29 10:54 ` [PATCH 01/10] define kernel symbol flags Siddharth Nayyar
2025-08-29 10:54 ` [PATCH 02/10] linker: add kflagstab section to vmlinux and modules Siddharth Nayyar
2025-08-29 10:54 ` [PATCH 03/10] modpost: create entries for kflagstab Siddharth Nayyar
2025-08-29 10:54 ` [PATCH 04/10] module loader: use kflagstab instead of *_gpl sections Siddharth Nayyar
2025-10-08 13:19 ` Petr Pavlu
2025-08-29 10:54 ` [PATCH 05/10] modpost: put all exported symbols in ksymtab section Siddharth Nayyar
2025-08-29 10:54 ` [PATCH 06/10] module loader: remove references of *_gpl sections Siddharth Nayyar
2025-10-08 13:22 ` Petr Pavlu
2025-08-29 10:54 ` [PATCH 07/10] linker: remove *_gpl sections from vmlinux and modules Siddharth Nayyar
2025-08-29 10:54 ` [PATCH 08/10] remove references to *_gpl sections in documentation Siddharth Nayyar
2025-10-08 13:24 ` Petr Pavlu
2025-08-29 10:54 ` [PATCH 09/10] modpost: add symbol import protection flag to kflagstab Siddharth Nayyar
2025-10-08 13:35 ` Petr Pavlu
2025-08-29 10:54 ` [PATCH 10/10] module loader: enforce symbol import protection Siddharth Nayyar
2025-10-08 15:35 ` Petr Pavlu
2025-09-01 12:27 ` [RFC PATCH 00/10] scalable symbol flags with __kflagstab Petr Pavlu
2025-09-03 23:28 ` Sid Nayyar
2025-09-08 10:09 ` Petr Pavlu
2025-09-15 15:53 ` Sid Nayyar
2025-09-22 11:41 ` Petr Pavlu
2025-09-26 0:11 ` Sid Nayyar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250829105418.3053274-1-sidnayyar@google.com \
--to=sidnayyar@google.com \
--cc=arnd@arndb.de \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=nathan@kernel.org \
--cc=nicolas.schier@linux.dev \
--cc=petr.pavlu@suse.com \
--cc=samitolvanen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®