From: Matthew Maurer <mmaurer@google.com>
To: masahiroy@kernel.org, ndesaulniers@google.com, ojeda@kernel.org,
gary@garyguo.net, mcgrof@kernel.org,
Alex Gaynor <alex.gaynor@gmail.com>
Cc: rust-for-linux@vger.kernel.org, linux-kbuild@vger.kernel.org,
linux-kernel@vger.kernel.org, neal@gompa.dev, marcan@marcan.st,
j@jannau.net, asahi@lists.linux.dev,
linux-modules@vger.kernel.org, samitolvanen@google.com,
"Matthew Maurer" <mmaurer@google.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>
Subject: [PATCH v6 0/5] Extended MODVERSIONS Support
Date: Tue, 15 Oct 2024 23:18:55 +0000 [thread overview]
Message-ID: <20241015231925.3854230-1-mmaurer@google.com> (raw)
This patch series is intended for use alongside the Implement
MODVERSIONS for RUST [1] series as a replacement for the symbol name
hashing approach used there to enable RUST and MODVERSIONS at the same
time.
Elsewhere, we've seen a desire for long symbol name support for LTO
symbol names [2], and the previous series came up [3] as a possible
solution rather than hashing, which some have objected [4] to.
This series adds a MODVERSIONS format which uses a section per column.
This avoids userspace tools breaking if we need to make a similar change
to the format in the future - we would do so by adding a new section,
rather than editing the struct definition. In the new format, the name
section is formatted as a concatenated sequence of NUL-terminated
strings, which allows for arbitrary length names.
Emitting the extended format is guarded by CONFIG_EXTENDED_MODVERSIONS,
but the kernel always knows how to validate both the original and
extended formats.
If you are testing this patch alongside RUST by manually removing the
!MODVERSIONS restriction (this series doesn't remove it, because the
CRCs don't mean what we'd want them to yet, we need the DWARF patch for
that) and have kernel hardening enabled, you may need the CPU
Mitigations [5] series. Without it, the foo.mod.o file produced by the
C compiler will reference __x86_return_thunk, but foo.o will not.
This means that the version table will not contain a version for
__x86_return_thunk, but foo.ko will reference it, which will result
in a version check failure.
This series depends upon the module verification refactor patches [6]
that were split off of v5.
[1] https://lore.kernel.org/all/20240617175818.58219-17-samitolvanen@google.com/
[2] https://lore.kernel.org/lkml/20240605032120.3179157-1-song@kernel.org/
[3] https://lore.kernel.org/lkml/ZoxbEEsK40ASi1cY@bombadil.infradead.org/
[4] https://lore.kernel.org/lkml/0b2697fd-7ab4-469f-83a6-ec9ebc701ba0@suse.com/
[5] https://lore.kernel.org/all/20240725183325.122827-1-ojeda@kernel.org/
[6] https://lore.kernel.org/linux-modules/20241015231651.3851138-1-mmaurer@google.com/T/#t
Changes in v6:
- Splits verification refactor Luis requested out to a separate change
- Clarifies commits around export_report.pl repairs
- Add CONFIG_EXTENDED_MODVERSIONS to control whether extended
information is included in the module, per Luis's request.
v5: https://lore.kernel.org/all/20240925233854.90072-1-mmaurer@google.com/
- Addresses Sami's comments from v3 that I missed in v4 (missing early
return, extra parens)
v4: https://lore.kernel.org/asahi/20240924212024.540574-1-mmaurer@google.com/
- Fix incorrect dot munging in PPC
v3: https://lore.kernel.org/lkml/87le0w2hop.fsf@mail.lhotse/T/
- Split up the module verification refactor into smaller patches, per
Greg K-H's suggestion.
v2: https://lore.kernel.org/all/20231118025748.2778044-1-mmaurer@google.com/
- Add loading/verification refactor before modifying, per Luis's request
v1: https://lore.kernel.org/rust-for-linux/20231115185858.2110875-1-mmaurer@google.com/
Matthew Maurer (5):
export_report: Rehabilitate script
modules: Support extended MODVERSIONS info
export_report: Tolerate additional `.mod.c` content
modpost: Produce extended MODVERSIONS information
export_report: Use new version info format
arch/powerpc/kernel/module_64.c | 23 ++++++++-
kernel/module/Kconfig | 8 +++
kernel/module/internal.h | 11 ++++
kernel/module/main.c | 92 ++++++++++++++++++++++++++++++---
kernel/module/version.c | 45 ++++++++++++++++
scripts/export_report.pl | 17 +++---
scripts/mod/modpost.c | 41 +++++++++++++++
7 files changed, 220 insertions(+), 17 deletions(-)
--
2.47.0.rc1.288.g06298d1525-goog
next reply other threads:[~2024-10-15 23:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 23:18 Matthew Maurer [this message]
2024-10-15 23:18 ` [PATCH v6 1/5] export_report: Rehabilitate script Matthew Maurer
2024-10-17 0:29 ` Sami Tolvanen
2024-10-21 18:42 ` Luis Chamberlain
2024-10-28 13:13 ` Masahiro Yamada
2024-10-15 23:18 ` [PATCH v6 2/5] modules: Support extended MODVERSIONS info Matthew Maurer
2024-10-21 18:44 ` Luis Chamberlain
2024-10-15 23:18 ` [PATCH v6 3/5] export_report: Tolerate additional `.mod.c` content Matthew Maurer
2024-10-15 23:18 ` [PATCH v6 4/5] modpost: Produce extended MODVERSIONS information Matthew Maurer
2024-10-17 0:25 ` Sami Tolvanen
2024-10-21 18:48 ` Luis Chamberlain
2024-10-21 18:50 ` Luis Chamberlain
2024-10-15 23:19 ` [PATCH v6 5/5] export_report: Use new version info format Matthew Maurer
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=20241015231925.3854230-1-mmaurer@google.com \
--to=mmaurer@google.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=asahi@lists.linux.dev \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=j@jannau.net \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=ndesaulniers@google.com \
--cc=neal@gompa.dev \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=tmgross@umich.edu \
/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