[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250829105418.3053274-1-sidnayyar@google.com>
Date: Fri, 29 Aug 2025 10:54:08 +0000
From: Siddharth Nayyar <sidnayyar@...gle.com>
To: Nathan Chancellor <nathan@...nel.org>, Luis Chamberlain <mcgrof@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>
Cc: Nicolas Schier <nicolas.schier@...ux.dev>, Petr Pavlu <petr.pavlu@...e.com>,
Arnd Bergmann <arnd@...db.de>, linux-kbuild@...r.kernel.org, linux-arch@...r.kernel.org,
linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
Siddharth Nayyar <sidnayyar@...gle.com>
Subject: [RFC PATCH 00/10] scalable symbol flags with __kflagstab
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
Powered by blists - more mailing lists