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
