public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <kees@kernel.org>
To: Petr Pavlu <petr.pavlu@suse.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Daniel Gomez <da.gomez@samsung.com>,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v1 0/3] module: Don't fail module loading when setting ro_after_init section RO failed
Date: Mon, 6 Jan 2025 16:13:29 -0800	[thread overview]
Message-ID: <202501061610.203636A9C@keescook> (raw)
In-Reply-To: <f0e892c7-43cd-4310-9d60-1d6e839f5bb2@suse.com>

On Fri, Jan 03, 2025 at 05:13:32PM +0100, Petr Pavlu wrote:
> On 12/5/24 20:46, Christophe Leroy wrote:
> > This series reworks module loading to avoid leaving the module in a
> > stale state when protecting ro_after_init section fails.
> > 
> > Once module init has succeded it is too late to cancel loading.

Is there at least a big WARN about the ro failing? That should let more
sensitive system owners react to the situation if it looks like an
active attack on memory protections.

(And maybe we should set a TAINT flag, but perhaps this is too specific
a failure mode for that?)

Also, why is it too late to cancel? Can we set the module to the
"Unloading" state to stop any dependent modules from loading on top of
it, and then request it unload?

-- 
Kees Cook

  parent reply	other threads:[~2025-01-07  0:13 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-05 19:46 [PATCH v1 0/3] module: Don't fail module loading when setting ro_after_init section RO failed Christophe Leroy
2024-12-05 19:46 ` [PATCH v1 1/3] module: Split module_enable_rodata_ro() Christophe Leroy
2024-12-05 19:46 ` [PATCH v1 2/3] module: Don't fail module loading when setting ro_after_init section RO failed Christophe Leroy
2024-12-05 19:46 ` [PATCH v1 3/3] module: pre-test setting ro_after_init data read-only Christophe Leroy
2024-12-11  4:29 ` [PATCH v1 0/3] module: Don't fail module loading when setting ro_after_init section RO failed Luis Chamberlain
2025-01-03 16:13 ` Petr Pavlu
2025-01-04  7:39   ` Christophe Leroy
2025-01-06 14:01     ` Petr Pavlu
2025-01-07  0:13   ` Kees Cook [this message]
2025-01-07 13:00     ` Daniel Gomez
2025-01-08 19:17     ` Luis Chamberlain

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=202501061610.203636A9C@keescook \
    --to=kees@kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=da.gomez@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=rppt@kernel.org \
    --cc=samitolvanen@google.com \
    --cc=tglx@linutronix.de \
    /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