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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <HKAPR02MB429186AF5DC0A187A345F3BCE0640@HKAPR02MB4291.apcprd02.prod.outlook.com>
Date:   Thu, 9 Jul 2020 07:18:01 +0000
From:   彭浩(Richard) <richard.peng@...o.com>
To:     Ard Biesheuvel <ardb@...nel.org>
CC:     Will Deacon <will@...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, 9 Jul 2020 at 09:50, 彭浩(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.
If this is the case I don't think I need to do anything, just return 0.What do you think should be 
done about this situation? Any Suggestions?
Thanks.
>Are you sure you have CONFIG_RANDOMIZE_BASE enabled?
>
CONFIG_RANDOMIZE_BASE = y or n has this warning (two servers, kernel version is different).

>> >In module_frob_arch_sections(), we count all such relocations that
>> >point to other sections, and allocate a PLT slot for each (and update
>> >plt_max_entries) accordingly. So this means that the relocation in
>> >question was disregarded, and this could happen for only two reasons:
>> >- the branch instruction and its target are both in the same section,
>> >in which case this section is *really* large,
>> >- CONFIG_RANDOMIZE_BASE is disabled, but you are still ending up in a
>> >situation where the modules are really far away from the core kernel
>> >or from other modules.
>> >
>> >Do you have a lot of [large] modules loaded when this happens?
>> I don’t think I have [large] modules.  I'll trace which module caused this warning.
>
>Yes please.
I can't print debug until someone else is not using the server.