[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 02 Aug 2016 13:12:02 +1000
From: Michael Ellerman <mpe@...erman.id.au>
To: Kees Cook <keescook@...omium.org>
Cc: "kernel-hardening\@lists.openwall.com" <kernel-hardening@...ts.openwall.com>, Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Andrew Morton <akpm@...ux-foundation.org>, "David S. Miller" <davem@...emloft.net>, Mauro Carvalho Chehab <mchehab@....samsung.com>, Jiri Slaby <jslaby@...e.cz>, Guenter Roeck <linux@...ck-us.net>, LKML <linux-kernel@...r.kernel.org>, "linuxppc-dev\@lists.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, Anton Blanchard <anton@...ba.org>, Alan Modra <amodra@...il.com>
Subject: Re: Re: Linker segfault on powerpc when CONFIG_LKDTM=y (was Re: [PATCH 3/5] lkdtm: add function for testing .rodata section)
Kees Cook <keescook@...omium.org> writes:
> On Mon, Aug 1, 2016 at 5:37 AM, Michael Ellerman <mpe@...erman.id.au> wrote:
>> Kees Cook <keescook@...omium.org> writes:
>>
>>> This adds a function that lives in the .rodata section. The section
>>> flags are corrected using objcopy since there is no way with gcc to
>>> declare section flags in an architecture-agnostic way.
>>>
>>> Signed-off-by: Kees Cook <keescook@...omium.org>
>>> ---
>>> drivers/misc/Makefile | 7 +++++++
>>> drivers/misc/lkdtm.h | 6 ++++++
>>> drivers/misc/lkdtm_core.c | 24 +++++++++++++++++-------
>>> drivers/misc/lkdtm_rodata.c | 10 ++++++++++
>>> 4 files changed, 40 insertions(+), 7 deletions(-)
>>> create mode 100644 drivers/misc/lkdtm.h
>>> create mode 100644 drivers/misc/lkdtm_rodata.c
>>
>> This is blowing up my linker :(
>>
>> scripts/link-vmlinux.sh: line 52: 36260 Segmentation fault (core dumped) ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${2} -T ${lds} ${KBUILD_VMLINUX_INIT} --start-group ${KBUILD_VMLINUX_MAIN} --end-group ${1}
>>
>> Haven't had a chance to debug it further.
>
> Argh. Do you want a quick fix for this now? I can add a PPC CONFIG
> blacklist for the rodata check, maybe?
Nah that's OK, none of our defconfigs have it enabled so it's not a real
blocker. It also builds OK as a module - though I haven't tested the
result yet.
> Also, what version of gcc? I'll see if I can reproduce this with a
> cross compiler...
The original hit was with gcc-5.3 (which is actually a x86->ppc cross):
http://kisskb.ellerman.id.au/kisskb/buildresult/12762730/
But I can also reproduce with 5.4, and 6.1.0.
Interestingly I *can't* reproduce with the Ubuntu x86->ppc cross
(5.4.0-6ubuntu1~16.04.1).
Those toolchains are all using binutils 2.26 AFAIK.
Going back to a really old toolchain (gcc 4.6.3/binutils 2.22) it does
build but I get these warnings:
powerpc64-linux-ld: drivers/misc/built-in.o: .opd is not a regular array of opd entries
powerpc64-linux-ld: drivers/built-in.o: .opd is not a regular array of opd entries
powerpc64-linux-ld: drivers/built-in.o: .opd is not a regular array of opd entries
powerpc64-linux-ld: drivers/built-in.o: .opd is not a regular array of opd entries
powerpc64-linux-ld: drivers/built-in.o: .opd is not a regular array of opd entries
So probably don't worry about it and we'll try and work it out on our end.
cheers
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
