From: Nicolas Pitre <nico@fluxnic.net>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Kees Cook <keescook@chromium.org>,
Russell King - ARM Linux <linux@armlinux.org.uk>,
stable@vger.kernel.org, linux-kernel@vger.kernel.org,
clang-built-linux@googlegroups.com, manojgupta@google.com,
natechancellor@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: explicitly place .fixup in .text
Date: Fri, 29 Nov 2019 16:33:16 -0500 (EST) [thread overview]
Message-ID: <nycvar.YSQ.7.76.1911291614480.8537@knanqh.ubzr> (raw)
In-Reply-To: <20191122185522.20582-1-ndesaulniers@google.com>
On Fri, 22 Nov 2019, Nick Desaulniers wrote:
> From: Kees Cook <keescook@chromium.org>
>
> There's an implicit dependency on the section ordering of the orphaned
> section .fixup that can break arm_copy_from_user if the linker places
> the .fixup section before the .text section. Since .fixup is not
> explicitly placed in the existing ARM linker scripts, the linker is free
> to order it anywhere with respect to the rest of the sections.
>
> Multiple users from different distros (Raspbian, CrOS) reported kernel
> panics executing seccomp() syscall with Linux kernels linked with LLD.
>
> Documentation/x86/exception-tables.rst alludes to the ordering
> dependency. The relevant quote:
>
> ```
> NOTE:
> Due to the way that the exception table is built and needs to be ordered,
> only use exceptions for code in the .text section. Any other section
> will cause the exception table to not be sorted correctly, and the
> exceptions will fail.
>
> Things changed when 64-bit support was added to x86 Linux. Rather than
> double the size of the exception table by expanding the two entries
> from 32-bits to 64 bits, a clever trick was used to store addresses
> as relative offsets from the table itself. The assembly code changed
> from::
>
> .long 1b,3b
> to:
> .long (from) - .
> .long (to) - .
>
> and the C-code that uses these values converts back to absolute addresses
> like this::
>
> ex_insn_addr(const struct exception_table_entry *x)
> {
> return (unsigned long)&x->insn + x->insn;
> }
> ```
>
> Since the addresses stored in the __ex_table are RELATIVE offsets and
> not ABSOLUTE addresses, ordering the fixup anywhere that's not
> immediately preceding .text causes the relative offset of the faulting
> instruction to be wrong, causing the wrong (or no) address of the fixup
> handler to looked up in __ex_table.
This explanation makes no sense.
The above is valid only when ARCH_HAS_RELATIVE_EXTABLE is defined. On
ARM32 it is not, nor would it make sense to be.
Nicolas
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-11-29 21:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 18:55 [PATCH] arm: explicitly place .fixup in .text Nick Desaulniers
2019-11-29 21:33 ` Nicolas Pitre [this message]
2019-12-03 23:42 ` Nick Desaulniers
2019-12-04 3:07 ` Nicolas Pitre
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=nycvar.YSQ.7.76.1911291614480.8537@knanqh.ubzr \
--to=nico@fluxnic.net \
--cc=clang-built-linux@googlegroups.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=manojgupta@google.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).