linux-kernel - Re: [PATCH 3/7] [HACK] x86: crypto: fix link error with LTO

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:   Fri, 2 Feb 2018 23:18:14 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Nicolas Pitre <nicolas.pitre@...aro.org>
Cc:     Andi Kleen <ak@...ux.intel.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH 3/7] [HACK] x86: crypto: fix link error with LTO

On Fri, Feb 2, 2018 at 8:49 PM, Nicolas Pitre <nicolas.pitre@...aro.org> wrote:
> On Fri, 2 Feb 2018, Arnd Bergmann wrote:
>
>> crypto_it_tab and the other symbols like it are defined in
>> crypto/aes_generic.c and exported for loadable modules. When
>> building with LTO and CONFIG_TRIM_UNUSED_KSYMS, the exports
>> are eliminated, since kbuild fails to take the users in
>> the arch/x86/crypto/aes-i586-asm_32.S assembler file into
>> account.
>>
>> This adds an ugly workaround by adding a reference to each symbol
>> into aes_glue.c, which gets linked together with the assembler
>> file.
>>
>> We obviously want to fix the CONFIG_TRIM_UNUSED_KSYMS logic
>> to do the right thing here instead, but I couldn't come up
>> with a good fix, so I use this instead to get a clean build
>> for testing.
>
> Could you give me the .config you used for this? So far I can't
> reproduce, and guessing with LTO takes lots of time.

I've uploaded my randconfig file to

https://pastebin.com/raw/iLk4sSpw

>> This fix only works most of the time, but I still ran into
>> some cases where combining an .S with a .c file did not
>> produce the correct .ko file, as the lto linker apparently
>> did not expect that kind of input. 'nm' on the file after
>> 'ld -r' showed only the contents of the assembler file, and
>> after the lto-ld stage, only the contents of the .c file
>> are there.
>
> 'ld -r' does not support mixed (LTO and non-LTO) objects.

Ok, that would explain it. I checked that CONFIG_THIN_ARCHIVES
is set here, but I see clearly that the module is linked using

x86_64-linux-ld -m elf_x86_64   -r -o arch/x86/crypto/aes-x86_64.o
arch/x86/crypto/aes-x86_64-asm_64.o arch/x86/crypto/aes_glue.o ;
scripts/mod/modpost arch/x86/crypto/aes-x86_64.o

       Arnd