linux-kernel - Re: [RFC PATCH 2/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 for Android: free password hash cracker in your pocket

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

Message-ID: <d2e5f644-500c-45a5-8606-159b513dcf19@csgroup.eu>
Date: Sat, 4 Jan 2025 08:42:54 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Petr Pavlu <petr.pavlu@...e.com>, Daniel Gomez <da.gomez@...sung.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
 Sami Tolvanen <samitolvanen@...gle.com>, Kees Cook <kees@...nel.org>,
 linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
 Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 2/3] module: Don't fail module loading when setting
 ro_after_init section RO failed



Le 03/01/2025 à 16:40, Petr Pavlu a écrit :
> On 12/10/24 11:49, Daniel Gomez wrote:>>> Do you envision that the userspace would handle this problem 
differently
>>> and it is worth adding the complexity?
>>
>> What complexity do you mean?
> 
> The complexity that I was referring to here is mainly the earlier
> described limitation of the current init_module() interface and the
> consistency of the module loader interface as a whole.
> 
> Another aspect is that a number of modules is loaded directly by the
> kernel via request_module(). I'm not sure how the new error would be
> handled in such cases. I suspect request_module() would be also only
> able to log it as a kernel warning.

And that's the same approach as for the core part of the kernel. Proper 
protection is verified by fonction rodata_test() which will just print 
an error when verification fails.

> 
> If I had to choose how to handle this corner case better (in long term),
> I would rather try to avoid the error in the first place, potentially as
> mentioned in my other reply by splitting set_memory_ro().
>