From: Arnd Bergmann <arnd@arndb.de>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: PaX Team <pageexec@freemail.hu>,
Laura Abbott <labbott@redhat.com>,
Kees Cook <keescook@chromium.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [kernel-hardening] Re: [PATCH] lkdtm: add test for executing .rodata
Date: Thu, 18 Feb 2016 13:07:24 +0100 [thread overview]
Message-ID: <3013719.NTkGVd5eeC@wuerfel> (raw)
In-Reply-To: <CAKv+Gu_ABQa4L7ZzHMD+-BPLtJf_UO9TfLy0jKFLfCsyQE6dLQ@mail.gmail.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: PaX Team <pageexec@freemail.hu>,
Laura Abbott <labbott@redhat.com>,
Kees Cook <keescook@chromium.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Mark Rutland <mark.rutland@arm.com>,
Jeremy Linton <jeremy.linton@arm.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] lkdtm: add test for executing .rodata
Date: Thu, 18 Feb 2016 13:07:24 +0100 [thread overview]
Message-ID: <3013719.NTkGVd5eeC@wuerfel> (raw)
In-Reply-To: <CAKv+Gu_ABQa4L7ZzHMD+-BPLtJf_UO9TfLy0jKFLfCsyQE6dLQ@mail.gmail.com>
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
next prev parent reply other threads:[~2016-02-18 12:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 21:49 [kernel-hardening] [PATCH] lkdtm: add test for executing .rodata Kees Cook
2016-02-16 21:49 ` Kees Cook
2016-02-17 1:06 ` [kernel-hardening] " Laura Abbott
2016-02-17 1:06 ` Laura Abbott
2016-02-17 20:29 ` [kernel-hardening] " Kees Cook
2016-02-17 20:29 ` Kees Cook
2016-02-17 21:06 ` [kernel-hardening] " Kees Cook
2016-02-17 21:06 ` Kees Cook
2016-02-18 10:32 ` [kernel-hardening] " PaX Team
2016-02-18 10:32 ` PaX Team
2016-02-18 11:34 ` [kernel-hardening] " Ard Biesheuvel
2016-02-18 11:34 ` Ard Biesheuvel
2016-02-18 11:55 ` [kernel-hardening] " Ard Biesheuvel
2016-02-18 11:55 ` Ard Biesheuvel
2016-02-18 12:07 ` Arnd Bergmann [this message]
2016-02-18 12:07 ` Arnd Bergmann
2016-02-18 12:46 ` [kernel-hardening] " Ard Biesheuvel
2016-02-18 12:46 ` Ard Biesheuvel
2016-02-18 20:04 ` [kernel-hardening] " Kees Cook
2016-02-18 20:04 ` Kees Cook
2016-02-18 21:27 ` [kernel-hardening] " PaX Team
2016-02-18 21:27 ` PaX Team
2016-02-22 20:46 ` [kernel-hardening] " Kees Cook
2016-02-22 20:46 ` Kees Cook
2016-02-22 23:21 ` [kernel-hardening] " PaX Team
2016-02-22 23:21 ` PaX Team
2016-02-23 20:53 ` [kernel-hardening] " Kees Cook
2016-02-23 20:53 ` Kees Cook
2016-02-23 22:00 ` [kernel-hardening] " PaX Team
2016-02-23 22:00 ` PaX Team
2016-02-23 22:02 ` [kernel-hardening] " Kees Cook
2016-02-23 22:02 ` Kees Cook
2016-02-23 20:31 ` [kernel-hardening] " David Brown
2016-02-23 20:51 ` Kees Cook
2016-02-17 21:44 ` Arnd Bergmann
2016-02-17 21:44 ` Arnd Bergmann
2016-02-17 21:45 ` [kernel-hardening] " Arnd Bergmann
2016-02-17 21:45 ` Arnd Bergmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3013719.NTkGVd5eeC@wuerfel \
--to=arnd@arndb.de \
--cc=ard.biesheuvel@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=jeremy.linton@arm.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=labbott@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pageexec@freemail.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.