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: <3a961c7a-d793-4319-ab78-af11f46587ff@csgroup.eu>
Date: Sat, 4 Jan 2025 08:39:03 +0100
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: Luis Chamberlain <mcgrof@...nel.org>,
 Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez
 <da.gomez@...sung.com>, Kees Cook <kees@...nel.org>,
 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



Le 03/01/2025 à 17:13, Petr Pavlu a écrit :
> 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.
>> If setting ro_after_init data section to read-only fails, all we can
>> do is to inform the user through a warning. This is what patch 2 does.
>>
>> Then patch 3 tries to go a bit further by testing the ability to write
>> protect ro-after-init section prior to initialising the module.
> 
> I've been holding off on applying this series to modules-next because
> there was still some discussion on the previous RFC version [1], and
> I wanted to give people more time to potentially comment.
> 
> Mike Rapoport also recently posted a series with a patch [2] that
> proposes restoring of large pages after fragmentation. Should the last
> patch here be then dropped?

Indeed, if the large pages are restored when bringing back the 
ro_after_init to RW, it defeats the purpose of patch 3.

So I agree, let's first apply patches 1 and 2 in order to fix the actual 
bug then see how we can improve as a second step.

> 
> [1] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-modules%2F737f952790c96a09ad5e51689918b97ef9b29174.1731148254.git.christophe.leroy%40csgroup.eu%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Ce1338eec4ee742a40b6208dd2c1192dc%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638715176198708012%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=B7qL4g0NUqBqdREndab5kywoOu2wsNYej6hqnIH10tk%3D&reserved=0
> [2] https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-modules%2F20241227072825.1288491-4-rppt%40kernel.org%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Ce1338eec4ee742a40b6208dd2c1192dc%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638715176198723794%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=eMxPsu43ByOjr7ny9Xg81ylWS6853dTU5MmU3J9e2hc%3D&reserved=0
>