linux-kernel - Re: [PATCH 3/3] static_call: Fix static_call

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] [day] [month] [year] [list]

Message-ID: <YFjVmFgXdsIIkGRV@gunter>
Date:   Mon, 22 Mar 2021 18:36:24 +0100
From:   Jessica Yu <jeyu@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Josh Poimboeuf <jpoimboe@...hat.com>, x86@...nel.org,
        jbaron@...mai.com, ardb@...nel.org, linux-kernel@...r.kernel.org,
        sumit.garg@...aro.org, oliver.sang@...el.com, jarkko@...nel.org
Subject: Re: [PATCH 3/3] static_call: Fix static_call_update() sanity check

+++ Peter Zijlstra [22/03/21 17:54 +0100]:
>On Mon, Mar 22, 2021 at 03:50:14PM +0100, Jessica Yu wrote:
>
>> It should be doable. If you want the exit sections to be treated the same as
>> module init, the following patch should stuff any exit sections into the module
>> init "region" (completely untested). Hence it should be freed together with the
>> init sections and it would identify as init through within_module_init(). Let
>> me know if this works for you.
>
>That does indeed seem to DTRT from a quick scan of module.c. Very nice
>tidy patch. I was afraid it'd be much worse.
>
>Assuming it actually works; for your Changelog:
>
>"Dynamic code patching (alternatives, jump_label and static_call) can
>have sites in __exit code, even it __exit is never executed. Therefore
>__exit must be present at runtime, at least for as long as __init code
>is.
>
>Additionally, for jump_label and static_call, the __exit sites must also
>identify as within_module_init(), such that the infrastructure is aware
>to never touch them after module init -- alternatives are only ran once
>at init and hence don't have this particular constraint.
>
>By making __exit identify as __init for UNLOAD_MODULE, the above is
>satisfied."

Thanks a lot for the changelog :-) I'll turn this into a formal patch
after some testing tomorrow.

Jessica