From: Nicolas Bouchinet <nicolas.bouchinet@oss.cyber.gouv.fr>
To: sashiko@lists.linux.dev
Cc: "Thomas Weißschuh" <linux@weissschuh.net>, bpf@vger.kernel.org
Subject: Re: [PATCH v5 02/14] lockdown: Make the relationship to MODULE_SIG a dependency
Date: Tue, 5 May 2026 14:27:41 +0200 [thread overview]
Message-ID: <afngZZcIZnZ2DrBC@archlinux> (raw)
In-Reply-To: <20260505093229.D8CD2C2BCB4@smtp.kernel.org>
> > diff --git a/security/lockdown/Kconfig b/security/lockdown/Kconfig
> > index e84ddf4840101..155959205b8ea 100644
> > --- a/security/lockdown/Kconfig
> > +++ b/security/lockdown/Kconfig
> > @@ -1,7 +1,7 @@
> > config SECURITY_LOCKDOWN_LSM
> > bool "Basic module for enforcing kernel lockdown"
> > depends on SECURITY
> > - select MODULE_SIG if MODULES
> > + depends on !MODULES || MODULE_SIG
>
> Will this change silently disable CONFIG_SECURITY_LOCKDOWN_LSM in existing
> defconfigs?
>
> Because Kconfig's savedefconfig strips out automatically selected symbols,
> many in-tree defconfigs contain CONFIG_SECURITY_LOCKDOWN_LSM=y but omit
> CONFIG_MODULE_SIG=y. Since CONFIG_MODULE_SIG has no default y, it will
> initialize to n.
>
> With CONFIG_MODULES=y and CONFIG_MODULE_SIG=n, this new dependency evaluates
> to n. As a result, Kconfig will drop CONFIG_SECURITY_LOCKDOWN_LSM from the
> final configuration without any warnings, leaving the kernel unprotected by
> lockdown. This also degrades discoverability, hiding the Lockdown LSM in
> menuconfig unless a user explicitly enables MODULE_SIG first.
I think the bot is correct, powerpc/configs/skiroot_defconfig,
powerpc/configs/ppc64_defconfig, s390/configs/debug_defconfig and
s390/configs/defconfig all set CONFIG_SECURITY_LOCKDOWN_LSM{,_EARLY}=y.
They also set CONFIG_MODULE_SIG_FORCE=y but do not set CONFIG_MODULE_SIG
directly. The new 'depends on' condition will thus evict
CONFIG_SECURITY_LOCKDOWN_LSM{,_EARLY} from the generated .config.
Nicolas
next prev parent reply other threads:[~2026-05-05 12:27 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-05 9:05 [PATCH v5 00/14] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 01/14] kbuild: generate module BTF based on vmlinux.unstripped Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 02/14] lockdown: Make the relationship to MODULE_SIG a dependency Thomas Weißschuh
2026-05-05 9:32 ` sashiko-bot
2026-05-05 12:27 ` Nicolas Bouchinet [this message]
2026-05-05 9:05 ` [PATCH v5 03/14] kbuild: rename the strip_relocs command Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 04/14] module: Drop pointless debugging message Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 05/14] module: Make mod_verify_sig() static Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 06/14] module: Switch load_info::len to size_t Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 07/14] module: Make module authentication usable without MODULE_SIG Thomas Weißschuh
2026-05-05 9:40 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 08/14] module: Move authentication logic into dedicated new file Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 09/14] module: Move signature type check out of mod_check_sig() Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 10/14] module: Prepare for additional module authentication mechanisms Thomas Weißschuh
2026-05-05 9:05 ` [PATCH v5 11/14] module: update timestamp of modules.order after modules are built Thomas Weißschuh
2026-05-05 9:41 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 12/14] module: Introduce hash-based integrity checking Thomas Weißschuh
2026-05-05 9:49 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 13/14] kbuild: move handling of module stripping to Makefile.lib Thomas Weißschuh
2026-05-05 9:35 ` sashiko-bot
2026-05-05 9:05 ` [PATCH v5 14/14] kbuild: make CONFIG_MODULE_HASHES compatible with module stripping Thomas Weißschuh
2026-05-05 10:04 ` sashiko-bot
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=afngZZcIZnZ2DrBC@archlinux \
--to=nicolas.bouchinet@oss.cyber.gouv.fr \
--cc=bpf@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=sashiko@lists.linux.dev \
/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