linux-kernel - Re: [PATCH] arm64/module-plts: Consider the special case where plt_max

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

Message-ID: <HKAPR02MB4291648701A6803290A17299E0610@HKAPR02MB4291.apcprd02.prod.outlook.com>
Date:   Tue, 14 Jul 2020 08:48:11 +0000
From:   彭浩(Richard) <richard.peng@...o.com>
To:     Will Deacon <will@...nel.org>
CC:     Ard Biesheuvel <ardb@...nel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64/module-plts: Consider the special case where
 plt_max_entries is 0

On Thu, Jul 09, 2020 at 07:18:01AM +0000,Peng Hao(Richard) wrote:
> On Thu, 9 Jul 2020 at 09:50, Peng Hao(Richard) <richard.peng@...o.com> wrote:
> >> >Apparently, you are hitting a R_AARCH64_JUMP26 or R_AARCH64_CALL26
> >> >relocation that operates on a b or bl instruction that is more than
> >> >128 megabytes away from its target.
> >> >
> >> My understanding is that a module that calls functions that are not part of the module will use PLT.
> >> Plt_max_entries =0 May occur if a module does not depend on other module functions.
> >>
> >
> >A PLT slot is allocated for each b or bl instruction that refers to a
> >symbol that lives in a different section, either of the same module
> > (e.g., bl in .init calling into .text), of another module, or of the
> >core kernel.
> >
> >I don't see how you end up with plt_max_entries in this case, though.
> if a module does not depend on other module functions, PLT entries in the module is equal to 0.

>This brings me back to my earlier question: if there are no PLT entries in
>the module, then count_plts() will not find any R_AARCH64_JUMP26 or
>R_AARCH64_CALL26 relocations that require PLTs and will therefore return 0.
>The absence of these relocations means that module_emit_plt_entry() will not
>be called by apply_relocate_add(), and so your patch should have no effect.
1.The module in question is the calling function from core kernel.( Ib_core.ko triggered the warning multiple times).
2. There are multiple threads loading IB_core.ko
[   73.388931]  ###cpu=33, name=ib_core, core_plts=0, init_plts=0  
[   73.402102]  #### cpu=33,pid=2297,name=ib_core, module_emit_plt_entry:plt_num_entries=1, plt_max_entries=0 (warning)
[   73.439391]  ###cpu=24, name=ib_core, core_plts=0, init_plts=0  
[   73.448617]  ###cpu=4, name=ib_core, core_plts=0, init_plts=0  
[   73.547535]  ###cpu=221, name=ib_core, core_plts=0, init_plts=0  
[   75.198075]  #### cpu=24,pid=2336,name=ib_core, module_emit_plt_entry:plt_num_entries=1, plt_max_entries=0 (warning)
[   75.489496]  #### cpu=4,pid=2344,name=ib_core, module_emit_plt_entry:plt_num_entries=1, plt_max_entries=0(warning)

I don't understand why count_plts returns 0 when CONFIG_RANDOMIZE_BASE=n for R_AARCH64_JUMP26 and R_AARCH64_CALL26.

3. Set CONFIG_ARM64_MODULE_PLTS=y and restart the server several times without triggering this warning.