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
| ||
|
Message-ID: <20231225040736.7htp2cfhocbw4hxw@M910t> Date: Mon, 25 Dec 2023 12:07:36 +0800 From: Changbin Du <changbin.du@...wei.com> To: Changbin Du <changbin.du@...wei.com> CC: Luis Chamberlain <mcgrof@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, <linux-modules@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Hui Wang <hw.huiwang@...wei.com>, Xiaoyi Su <suxiaoyi@...wei.com>, Jeffrey Hugo <jhugo@...eaurora.org>, Stephen Rothwell <sfr@...b.auug.org.au> Subject: Re: [PATCH] modules: wait do_free_init correctly On Thu, Dec 21, 2023 at 10:30:37AM +0800, Changbin Du wrote: > On Wed, Dec 20, 2023 at 06:32:39AM -0800, Luis Chamberlain wrote: > > On Wed, Dec 20, 2023 at 01:27:51PM +0800, Changbin Du wrote: > > > On Tue, Dec 19, 2023 at 01:52:03PM -0800, Luis Chamberlain wrote: > > > > On Tue, Dec 19, 2023 at 12:51:51PM -0800, Andrew Morton wrote: > > > > > On Tue, 19 Dec 2023 22:12:31 +0800 Changbin Du <changbin.du@...wei.com> wrote: > > > > > > > > > > > The commit 1a7b7d922081 ("modules: Use vmalloc special flag") moves > > > > > > do_free_init() into a global workqueue instead of call_rcu(). So now > > > > > > we should wait it via flush_work(). > > > > > > > > > > What are the runtime effects of this change? > > > > > > > > Indeed that's needed given how old this culprit commit is: > > > > > > > > git describe --contains 1a7b7d922081 > > > > v5.2-rc1~192^2~5 > > > > > > > > Who did this work and for what reason? What triggered this itch? > > > > > > > Seems the waiting was introduced by commit ae646f0b9ca ("init: fix false positives > > > in W+X checking"). > > > > > > As what I have observed, mark_readonly() is only invoked by the first user mode > > > thread function kernel_init(), which is before userspace /init. So is it real > > > possible we have loaded modules at this point? > > > > Are you saying we don't free any module inits at all then? I asked a lot > > of questions and your answers seem slim. > > > Yes, indeed no module loaded at all before mark_readonly(), at least on my desktop. > So I think we can just delete this synchronization. I am not sure whether there are > any historical reasons. > I thought about it again, kernel doesn't prevent any drivers from calling request_module() before init. So it's possible that some particular modules do behave this way. I will send an updated one to fix the compilation issue for no CONFIG_MODULES. -- Cheers, Changbin Du
Powered by blists - more mailing lists