linux-kernel - Re: Re: [PATCH 1/1] arm/module: maximum utilization of module area.

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]

Date:   Mon, 12 Dec 2016 16:57:44 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Vaneet Narang <v.narang@...sung.com>,
        "panand@...hat.com" <panand@...hat.com>,
        "arnd@...db.de" <arnd@...db.de>,
        Russell King - ARM Linux <linux@...linux.org.uk>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ajeet Kumar Yadav <ajeet.y@...sung.com>,
        "chris.brandt@...esas.com" <chris.brandt@...esas.com>,
        "ssantosh@...nel.org" <ssantosh@...nel.org>,
        Maninder Singh <maninder1.s@...sung.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        PANKAJ MISHRA <pankaj.m@...sung.com>
Subject: Re: Re: [PATCH 1/1] arm/module: maximum utilization of module area.

On 12 December 2016 at 15:28, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> On Mon, 12 Dec 2016, Vaneet Narang wrote:
>
>> Hi,
>>
>> >A PC24 relocation has a range of +/-32MB.  This means that where-ever
>> >the module is placed, it must be capable of reaching any function
>> >within the kernel text, which may itself be quite large (eg, 8MB, or
>> >possibly larger).  The module area exists to allow modules to be
>> >located in an area where PC24 relocations are able to reach all of the
>> >kernel text on sensibly configured kernels, thereby allowing for
>> >optimal performance.
>> >
>> >If you wish to load large modules, then enable ARM_MODULE_PLTS, which
>> >will use the less efficient PLT method (which is basically an indirect
>> >function call) for relocations that PC24 can't handle, and will allow
>> >the module to be loaded into the vmalloc area.
>> >
>> >Growing the module area so that smaller modules also get penalised by
>> >the PLT indirection is not sane.
>>
>> This is exactly what i am saying. These changes are useful to accomdate
>> 22MB modules without enabling ARM_MODULE_PLTS.
>
> I think you need to figure out why you need such a huge module in the
> first place.  That is very uncommon indeed.
>

Also, note that the module PLT code was recently optimized, to remove
some pathological behavior which severely affected load times of large
modules.

Can you quantify the performance hit you are taking when using module
PLTs? And the actual increase in memory footprint?