linux-kernel - Re: [PATCH] modules: wait do_free

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: <20231220052751.3zcnsnvjk5vf5t7j@M910t>
Date: Wed, 20 Dec 2023 13:27:51 +0800
From: Changbin Du <changbin.du@...wei.com>
To: Luis Chamberlain <mcgrof@...nel.org>
CC: Andrew Morton <akpm@...ux-foundation.org>, Changbin Du
	<changbin.du@...wei.com>, <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>
Subject: Re: [PATCH] modules: wait do_free_init correctly

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?

Cc Jeffrey Hugo <jhugo@...eaurora.org>
> Is it perhaps for an out of tree driver that did something funky
> on its module exit?
> 
> As per Documentation/RCU/rcubarrier.rst rcu_barrier will ensure the
> callbacks complete, so interms of determinism both mechanisms will
> have waited for the free. It seems we're now just limiting the scope.
> 
> This could also mean initialization grew used to having RCU calls on
> init complete at this point in time, even for modules, and so localizing
> this wait may now also introduce other unexpected behaviour.
> 
>   Luis

-- 
Cheers,
Changbin Du