Stable Archive on lore.kernel.org
 help / color / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: "Will Deacon" <will@kernel.org>,
	"Fāng-ruì Sòng" <maskray@google.com>,
	"Kees Cook" <keescook@chromium.org>,
	"Dmitry Vyukov" <dvyukov@google.com>,
	"Peter Oberparleiter" <oberpar@linux.ibm.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	kernel-team <kernel-team@android.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Peter Smith" <Peter.Smith@arm.com>,
	clang-built-linux <clang-built-linux@googlegroups.com>,
	"# 3.4.x" <stable@vger.kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>,
	"Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
Date: Wed, 21 Oct 2020 08:58:34 +0200
Message-ID: <CAMj1kXF-PFjG7sfdgCsnW-u-bd5yg+j3EiZUO8jYHMnb7bDttw@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOd=ZJjYOVubjHN6DFuopMP7jg9PAxGHhOPVu6KefPMNfkg@mail.gmail.com>

On Tue, 20 Oct 2020 at 22:16, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Tue, Oct 20, 2020 at 10:57 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Fri, 16 Oct 2020 10:53:39 -0700, Nick Desaulniers wrote:
> > > With CONFIG_EXPERT=y, CONFIG_KASAN=y, CONFIG_RANDOMIZE_BASE=n,
> > > CONFIG_RELOCATABLE=n, we observe the following failure when trying to
> > > link the kernel image with LD=ld.lld:
> > >
> > > error: section: .exit.data is not contiguous with other relro sections
> > >
> > > ld.lld defaults to -z relro while ld.bfd defaults to -z norelro. This
> > > was previously fixed, but only for CONFIG_RELOCATABLE=y.
> >
> > Applied to arm64 (for-next/core), thanks!
> >
> > [1/1] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
> >       https://git.kernel.org/arm64/c/3b92fa7485eb
>
> IF we wanted to go further and remove `-z norelro`, or even enable `-z
> relro` for aarch64, then we would have to detangle some KASAN/GCOV
> generated section discard spaghetti.

Why on earth would we want that?

> Fangrui did some more digging
> and found that .fini_array.* sections were relro (read only after
> relocations, IIUC), so adding them to EXIT_DATA
> (include/asm-generic/vmlinux.lds.h) was causing them to get included
> in .exit.data (arch/arm64/kernel/vmlinux.lds.S) making that relro.
> There's some history here with commits:
>
> - e41f501d39126 ("vmlinux.lds: account for destructor sections")
> - 8dcf86caa1e3da ("vmlinux.lds.h: Fix incomplete .text.exit discards")
> - d812db78288d7 ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections")
>
> It seems the following works for quite a few different
> configs/toolchains I played with, but the big IF is whether enabling
> `-z relro` is worthwhile?  If the kernel does respect that mapping,
> then I assume that's a yes, but I haven't checked yet whether relro is
> respected within the kernel (`grep -rn RELRO` turns up nothing
> interesting).  I also haven't checked yet whether all supported
> versions of GNU ld.bfd support -z relro (guessing not, since a quick
> test warns: `aarch64-linux-gnu-ld: warning: -z relro ignored` for
> v2.34.90.20200706, may be holding it wrong).
>

RELRO just moves statically initialized const pointers into a separate
section so we can place it in a way that allows us to easily map it
r/w during load, and switch it over to r/o once the relocations have
been applied.

On AArch64, we don't even use -fpic to build the kernel, and load time
relocations may appear everywhere in .text, .rodata etc etc, which is
absolutely fine given that we apply the relocations way before we
finalize the kernel mappings. This means that, in our case, statically
initialized const pointers will be mapped r/o already, and we don't
need RELRO.

In general, we should ensure that the 'relocatable bare metal' case
doesn't get snowed under, as toolchain development is [understandably]
very focused on hosted binaries that use shared libraries, where
things like CoW footprint, ELF symbol preemption, text relocations and
RELRO sections actually matter. For bare metal, it is quite the
opposite: text relocations are fine, there is no CoW so minimizing the
footprint of the .so pages that are modified due to relocations is
unnecessary, and symbols cannot be preempted either. So many of the
shared library tricks actually make things worse for us, because we
have to work around them while they have no benefit for us.

I have suggested this before, but perhaps we should have a
-mcmodel=kernel (like x86 does) that takes these things into account?
As a start, it could imply -cmodel=small (which we rely on today), but
with guarantees that the generated code is position independent, but
without GOT indirections, and that the resulting object code can be
linked with -pie (so that we have access to the load time relocations
in the bare metal binary itself). This is something we rely on today,
and happens to work in practice, but this could easily break in the
future.




> (Fangrui also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97507
> in regards to GCOV+GCC)
>
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index cd14444bf600..64578c998e53 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -744,7 +744,6 @@
>
>  #define EXIT_DATA                                                      \
>         *(.exit.data .exit.data.*)                                      \
> -       *(.fini_array .fini_array.*)                                    \
>         *(.dtors .dtors.*)                                              \
>         MEM_DISCARD(exit.data*)                                         \
>         MEM_DISCARD(exit.rodata*)
> @@ -995,6 +994,7 @@
>  #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
>  # ifdef CONFIG_CONSTRUCTORS
>  #  define SANITIZER_DISCARDS                                           \
> +       *(.fini_array .fini_array.*)                                    \
>         *(.eh_frame)
>  # else
>  #  define SANITIZER_DISCARDS                                           \
> @@ -1005,8 +1005,16 @@
>  # define SANITIZER_DISCARDS
>  #endif
>
> +#if defined(CONFIG_GCOV_KERNEL) && defined(CONFIG_CC_IS_GCC)
> +# define GCOV_DISCARDS                                                 \
> +       *(.fini_array .fini_array.*)
> +#else
> +# define GCOV_DISCARDS
> +#endif
> +
>  #define COMMON_DISCARDS
>          \
>         SANITIZER_DISCARDS                                              \
> +       GCOV_DISCARDS                                                   \
>         *(.discard)                                                     \
>         *(.discard.*)                                                   \
>         *(.modinfo)                                                     \
> --
> Thanks,
> ~Nick Desaulniers

  reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 17:53 Nick Desaulniers
2020-10-20 17:57 ` Will Deacon
2020-10-20 20:16   ` Nick Desaulniers
2020-10-21  6:58     ` Ard Biesheuvel [this message]
2020-12-14 21:44   ` Nick Desaulniers
2020-12-14 23:18     ` Alan Modra
2020-12-14 23:33       ` Nick Desaulniers
2020-12-17  0:40         ` [PATCH] arm64: link with -z norelro for LLD or aarch64-elf Nick Desaulniers
2020-12-17 12:01           ` Will Deacon
2020-12-17 21:07             ` Nick Desaulniers
2020-12-18  0:24               ` [PATCH v2] " Nick Desaulniers
2020-12-18  2:36                 ` Nathan Chancellor
2021-01-05 12:26                 ` Catalin Marinas
2020-12-17 19:29           ` [PATCH] " Ard Biesheuvel

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=CAMj1kXF-PFjG7sfdgCsnW-u-bd5yg+j3EiZUO8jYHMnb7bDttw@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=Peter.Smith@arm.com \
    --cc=arnd@arndb.de \
    --cc=catalin.marinas@arm.com \
    --cc=clang-built-linux@googlegroups.com \
    --cc=dvyukov@google.com \
    --cc=keescook@chromium.org \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maskray@google.com \
    --cc=ndesaulniers@google.com \
    --cc=oberpar@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=will@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

Stable Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/stable/0 stable/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 stable stable/ https://lore.kernel.org/stable \
		stable@vger.kernel.org
	public-inbox-index stable

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.stable


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git