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>] [day] [month] [year] [list]
Date:   Fri, 10 Jul 2020 10:17:03 +0000
From:   彭浩(Richard) <richard.peng@...o.com>
To:     Will Deacon <will@...nel.org>, Ard Biesheuvel <ardb@...nel.org>
CC:     "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.
>
>You seem to be saying that module_emit_plt_entry() _is_ being called,
>despite count_plts() returning 0. One way that can happen is if PLTs are
>needed for branches within a single, very large text section, but you also
>say that's not the case.
>
One of yesterday's reply was wrong. Warning appears on the two servers whose CONFIG_RANDOMIZE_BASE is n.
there is a server is someone copied a new config, which can enable CONFIG_RANDOMIZE_BASE,
 compiled the kernel, but has not restarted the host. @Ard

>So I think we need more information from you so that we can either reproduce
>this ourselves, or better understand where things are going wrong.
>
After I add the print information, the module that triggered the warning differs each time I restart the host.
>Finally, you said that your kernel is "5.6.0-rc3+". Are you able to
>reproduce with mainline (5.8-rc4)?
>
I will try it.
>Will
>
>P.S. whenever you reply, the mail threading breaks :(
Maybe the mailbox client automatically appends Chinese characters.
I'll adjust it and see if I can fix it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ