[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3013719.NTkGVd5eeC@wuerfel>
Date: Thu, 18 Feb 2016 13:07:24 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: PaX Team <pageexec@...email.hu>, Laura Abbott <labbott@...hat.com>, Kees Cook <keescook@...omium.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Mark Rutland <mark.rutland@....com>, Jeremy Linton <jeremy.linton@....com>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lkdtm: add test for executing .rodata
On Thursday 18 February 2016 12:34:50 Ard Biesheuvel wrote:
>
> We have __section() as an alias for __attribute__((__section__())), so
> we could use that instead.
>
> However, that does not fix the issue Kees is trying to solve, where a
> .rodata section is emitted with the "x" bit set, which causes the
> linker to complain:
>
> /tmp/cc50ffWw.s: Assembler messages:
> /tmp/cc50ffWw.s:2: Warning: setting incorrect section attributes for
> .rodata.text
>
> I wonder if we could get away with doing something like
>
> AFLAGS_lkdtm.o += -Wa,-W
>
> here? This just hides the warnings, but may result in the .rodata
> section in the vmlinux file to have X permissions as well. I don't
> think anyone uses an ELF loader to load their kernel, but who knows
> ...
Don't we also get a warning when we link objects with conflicting
section attributes?
Maybe a solution would be to define a separate section for this one
function, and then use a linker script to move it into .rodata?
Or maybe "objcopy --set-section-flags --rename-section"?
Arnd
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.
