Re: [PATCH v1 0/3] module: Don't fail module loading when setting ro_after_init section RO failed

[Daniel Gomez]

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@xxxxxxxxxxxxxxxxxxxxxx/

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