linux-kernel - Re: eh_frame confusion

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

Message-Id: <1583411741.zbaz5p86qy.naveen@linux.ibm.com>
Date:   Thu, 05 Mar 2020 18:11:06 +0530
From:   "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>
To:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: eh_frame confusion

Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@...ux.ibm.com> writes:
>> Rasmus Villemoes wrote:
>>> I'm building a ppc32 kernel, and noticed that after upgrading from gcc-7
>>> to gcc-8 all object files now end up having .eh_frame section. For
>>> vmlinux, that's not a problem, because they all get discarded in
>>> arch/powerpc/kernel/vmlinux.lds.S . However, they stick around in
>>> modules, which doesn't seem to be useful - given that everything worked
>>> just fine with gcc-7, and I don't see anything in the module loader that
>>> handles .eh_frame.
>>> 
>>> The reason I care is that my target has a rather tight rootfs budget,
>>> and the .eh_frame section seem to occupy 10-30% of the file size
>>> (obviously very depending on the particular module).
>>> 
>>> Comparing the .foo.o.cmd files, I don't see change in options that might
>>> explain this (there's a bunch of new -Wno-*, and the -mspe=no spelling
>>> is apparently no longer supported in gcc-8). Both before and after, there's
>>> 
>>> -fno-dwarf2-cfi-asm
>>> 
>>> about which gcc's documentation says
>>> 
>>> '-fno-dwarf2-cfi-asm'
>>>      Emit DWARF unwind info as compiler generated '.eh_frame' section
>>>      instead of using GAS '.cfi_*' directives.
>>> 
>>> Looking into where that comes from got me even more confused, because
>>> both arm and unicore32 say
>>> 
>>> # Never generate .eh_frame
>>> KBUILD_CFLAGS           += $(call cc-option,-fno-dwarf2-cfi-asm)
>>> 
>>> while the ppc32 case at hand says
>>> 
>>> # FIXME: the module load should be taught about the additional relocs
>>> # generated by this.
>>> # revert to pre-gcc-4.4 behaviour of .eh_frame
>>
>> Michael opened a task to look into this recently and I had spent some 
>> time last week on this. The original commit/discussion adding 
>> -fno-dwarf2-cfi-asm refers to R_PPC64_REL32 relocations not being 
>> handled by our module loader:
>> http://lkml.kernel.org/r/20090224065112.GA6690@bombadil.infradead.org
> 
> I opened that issue purely based on noticing the wart in the Makefile,
> not because I'd actually tested it.
> 
>> However, that is now handled thanks to commit 9f751b82b491d:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f751b82b491d
> 
> Haha, written by me, what an idiot.
> 
> So the Makefile hack can presumably be dropped, because the module
> loader can handle the relocations.
> 
> And then maybe we also want to turn off the unwind tables, but that
> would be a separate patch.
> 
>> I did a test build and a simple module loaded fine, so I think 
>> -fno-dwarf2-cfi-asm is not required anymore, unless Michael has seen 
>> some breakages with it. Michael?
> 
> No, as I said above it was just reading the Makefile.

Ok, thanks for clarifying. To test, I did 'allmodconfig' builds across 
three environments:
- gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008 -- ppc64le
- gcc (SUSE Linux) 7.5.0 -- ppc64le
- gcc (GCC) 8.2.1 20181215 (Red Hat 8.2.1-6) -- ppc64 (BE)

Then, used the below command to list all relocations in the modules:
$ find . -name '*.ko' | xargs -n 1 readelf -Wr  | grep -v "Relocation " | grep -v "Offset " | cut -d' ' -f4 | sort | uniq

R_PPC64_ADDR32
R_PPC64_ADDR64
R_PPC64_ENTRY
R_PPC64_REL24
R_PPC64_REL32
R_PPC64_REL64
R_PPC64_TOC
R_PPC64_TOC16_HA
R_PPC64_TOC16_LO
R_PPC64_TOC16_LO_DS

All three environments show up similar set of relocations, all of which 
we handle in the module loader today.

If Rasmus/Christophe can confirm that this is true for ppc32 as well, 
then we should be fine.

- Naveen