From: Petr Pavlu <petr.pavlu@suse.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>,
Daniel Gomez <da.gomez@samsung.com>, Kees Cook <kees@kernel.org>,
Petr Mladek <pmladek@suse.com>,
Jani Nikula <jani.nikula@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
John Ogness <john.ogness@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] module: Taint the kernel when write-protecting ro_after_init fails
Date: Thu, 6 Mar 2025 11:46:27 +0100 [thread overview]
Message-ID: <a9b364ea-e914-47c7-bb68-627fe1b668bd@suse.com> (raw)
In-Reply-To: <20250306103712.29549-1-petr.pavlu@suse.com>
+To: Christophe Leroy <christophe.leroy@csgroup.eu>
On 3/6/25 11:36, Petr Pavlu wrote:
> In the unlikely case that setting ro_after_init data to read-only fails, it
> is too late to cancel loading of the module. The loader then issues only
> a warning about the situation. Given that this reduces the kernel's
> protection, it was suggested to make the failure more visible by tainting
> the kernel.
>
> Allow TAINT_BAD_PAGE to be set per-module and use it in this case. The flag
> is set in similar situations and has the following description in
> Documentation/admin-guide/tainted-kernels.rst: "bad page referenced or some
> unexpected page flags".
>
> Adjust the warning that reports the failure to avoid references to internal
> functions and to add information about the kernel being tainted, both to
> match the style of other messages in the file. Additionally, merge the
> message on a single line because checkpatch.pl recommends that for the
> ability to grep for the string.
>
> Suggested-by: Kees Cook <kees@kernel.org>
> Signed-off-by: Petr Pavlu <petr.pavlu@suse.com>
> ---
> I opted to use TAINT_BAD_PAGE for now because it seemed unnecessary to me
> to introduce a new flag only for this specific case. However, if we end up
> similarly checking set_memory_*() in the boot context, a separate flag
> would be probably better.
> ---
> kernel/module/main.c | 7 ++++---
> kernel/panic.c | 2 +-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 1fb9ad289a6f..8f424a107b92 100644
> --- a/kernel/module/main.c
> +++ b/kernel/module/main.c
> @@ -3030,10 +3030,11 @@ static noinline int do_init_module(struct module *mod)
> rcu_assign_pointer(mod->kallsyms, &mod->core_kallsyms);
> #endif
> ret = module_enable_rodata_ro_after_init(mod);
> - if (ret)
> - pr_warn("%s: module_enable_rodata_ro_after_init() returned %d, "
> - "ro_after_init data might still be writable\n",
> + if (ret) {
> + pr_warn("%s: write-protecting ro_after_init data failed with %d, the data might still be writable - tainting kernel\n",
> mod->name, ret);
> + add_taint_module(mod, TAINT_BAD_PAGE, LOCKDEP_STILL_OK);
> + }
>
> mod_tree_remove_init(mod);
> module_arch_freeing_init(mod);
> diff --git a/kernel/panic.c b/kernel/panic.c
> index d8635d5cecb2..794c443bfb5c 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -497,7 +497,7 @@ const struct taint_flag taint_flags[TAINT_FLAGS_COUNT] = {
> TAINT_FLAG(CPU_OUT_OF_SPEC, 'S', ' ', false),
> TAINT_FLAG(FORCED_RMMOD, 'R', ' ', false),
> TAINT_FLAG(MACHINE_CHECK, 'M', ' ', false),
> - TAINT_FLAG(BAD_PAGE, 'B', ' ', false),
> + TAINT_FLAG(BAD_PAGE, 'B', ' ', true),
> TAINT_FLAG(USER, 'U', ' ', false),
> TAINT_FLAG(DIE, 'D', ' ', false),
> TAINT_FLAG(OVERRIDDEN_ACPI_TABLE, 'A', ' ', false),
>
> base-commit: 48a5eed9ad584315c30ed35204510536235ce402
next prev parent reply other threads:[~2025-03-06 10:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-06 10:36 [PATCH] module: Taint the kernel when write-protecting ro_after_init fails Petr Pavlu
2025-03-06 10:46 ` Petr Pavlu [this message]
2025-03-06 16:57 ` Luis Chamberlain
2025-03-12 15:45 ` Vlastimil Babka
2025-03-12 16:30 ` Kees Cook
2025-03-12 17:38 ` Luis Chamberlain
2025-03-14 16:48 ` Christophe Leroy
2025-03-14 19:19 ` Kees Cook
2025-03-20 12:33 ` Daniel Gomez
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=a9b364ea-e914-47c7-bb68-627fe1b668bd@suse.com \
--to=petr.pavlu@suse.com \
--cc=akpm@linux-foundation.org \
--cc=christophe.leroy@csgroup.eu \
--cc=da.gomez@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=jani.nikula@intel.com \
--cc=john.ogness@linutronix.de \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=pmladek@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.