linux-kernel - Re: [PATCH v1 0/3] module: Don't fail module loading when setting ro_after

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250107130008.nieaxsjpptwbwe5d@AALNPWDAGOMEZ1.aal.scsc.local>
Date: Tue, 7 Jan 2025 14:00:08 +0100
From: Daniel Gomez <da.gomez@...sung.com>
To: Kees Cook <kees@...nel.org>
CC: Petr Pavlu <petr.pavlu@...e.com>, Christophe Leroy
	<christophe.leroy@...roup.eu>, Luis Chamberlain <mcgrof@...nel.org>, Sami
	Tolvanen <samitolvanen@...gle.com>, <linux-modules@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, Thomas Gleixner <tglx@...utronix.de>, Mike
	Rapoport <rppt@...nel.org>
Subject: Re: [PATCH v1 0/3] module: Don't fail module loading when setting
 ro_after_init section RO failed

On Mon, Jan 06, 2025 at 04:13:29PM -0800, Kees Cook wrote:
> 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.

Yes, there is. But I think only the first time a module fails. IIUC,
any subsequent modules failing will not warn anything, is that right?
However, I think this should suffice to know a system is vulnerable but
will not know the full list of the actual vulnerable modules.

> 
> (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?

I think Luis summarized it here [1]. Quoting him from that thread:

	Sadly there are a few issues with trying to get to call mod->exit():
	
	- We should try try_stop_module()  and that can fail
	- source_list may not be empty and that would block removal
	- mod->exit may not exist

https://lore.kernel.org/all/Zuv0nmFblHUwuT8v@bombadil.infradead.org/

Module loading goes from UNFORMED to LIVE during the initialization.
And once it's LIVE we do the ro_after_init memory protection. I'm not
sure if an intermediate stage can be added so ro_after_init is performed
and module is unloaded when this fails? I guess init does not necessary
mean LIVE.

Daniel

> 
> -- 
> Kees Cook