From: Ard Biesheuvel <ardb@kernel.org>
To: Fangrui Song <maskray@google.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Kees Cook <keescook@chromium.org>,
Mark Rutland <mark.rutland@arm.com>,
Nathan Chancellor <nathan@kernel.org>,
Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [RFC PATCH 2/2] arm64: kernel: switch to PIE code generation for relocatable kernels
Date: Fri, 29 Apr 2022 09:27:27 +0200 [thread overview]
Message-ID: <CAMj1kXHJb0EJPtQP1c=2X0eWg_6s0FyLqpqjauKbt5ktjhS9CA@mail.gmail.com> (raw)
In-Reply-To: <20220429070318.iwj3j5lpfkw4t7g2@google.com>
On Fri, 29 Apr 2022 at 09:03, Fangrui Song <maskray@google.com> wrote:
>
> On 2022-04-28, Ard Biesheuvel wrote:
> >On Thu, 28 Apr 2022 at 20:53, Nick Desaulniers <ndesaulniers@google.com> wrote:
> >>
> >> On Wed, Apr 27, 2022 at 11:57 PM Fangrui Song <maskray@google.com> wrote:
> >> >
> >> > On 2022-04-28, Ard Biesheuvel wrote:
> >> > >On Thu, 28 Apr 2022 at 04:40, Fangrui Song <maskray@google.com> wrote:
> >> > >>
> >> > >> On 2022-04-27, Ard Biesheuvel wrote:
> >> > >> >Fortunately, we can convince the compiler to handle this in a way that
> >> > >> >is a bit more suitable for freestanding binaries such as the kernel, by
> >> > >> >setting the 'hidden' visibility #pragma, which informs the compiler that
> >> > >> >symbol preemption or CoW footprint are of no concern to us, and so
> >> > >> >PC-relative references that are resolved at link time are perfectly
> >> > >> >fine.
> >> > >>
> >> > >> Agree
> >> > >>
> >> > >
> >> > >The only unfortunate thing is that -fvisibility=hidden does not give
> >> > >us the behavior we want, and we are forced to use the #pragma instead.
> >> >
> >> > Right. For a very long time there had been no option controlling the
> >> > access mode for undefined symbols (-fvisibility= is for defined
> >> > symbols).
> >> >
> >> > I added -fdirect-access-external-data to Clang which supports
> >> > many architectures (x86, aarch64, arm, riscv, ...).
> >> > GCC's x86 port added -mdirect-extern-access in 2022-02 (not available on aarch64).
> >> >
> >> > The use of `#pragma GCC visibility push(hidden)` looks good as a
> >> > portable solution.
> >>
> >> Portable, sure, which is fine for now.
> >>
> >> But there's just something about injecting a header into ever TU via
> >> -include in order to set a pragma and that there's such pragmas
> >> effecting codegen that makes my skin crawl.
> >>
> >> Perhaps we can come up with a formal feature request for toolchain
> >> vendors for an actual command line flag?
> >>
> >> Does the pragma have the same effect as
> >> `-fdirect-access-external-data`/`-mdirect-extern-access`, or wvisould
> >> this feature request look like yet another distinct flag?
>
> `#pragma GCC visibility push(hidden)` is very similar to
> -fvisibility=hidden -fdirect-access-external-data with Clang.
> In Clang there are only two differences:
>
> // TLS initial-exec model with -fdirect-access-external-data;
> // TLS local-exec model with `#pragma GCC visibility push(hidden)`
> extern __thread int var;
> int foo() { return var; }
>
> // hidden visibility suppresses -fno-plt.
> // -fdirect-access-external-data / GCC -mdirect-extern-access doesn't suppress -fno-plt.
> extern int bar();
> int foo() { return bar() + 2; }
>
>
> The kernel uses neither TLS nor -fno-plt, so -fvisibility=hidden
> -fdirect-access-external-data can replace `#pragma GCC visibility
> push(hidden)`.
>
OK. But you mentioned that GCC does not implement
-mdirect-extern-access for AArch64, right? So for now, the pragma is
the only portable option we have.
> >I agree that this is rather nasty. What I don't understand is why
> >-fvisibility=hidden gives different behavior to begin with, or why
> >-ffreestanding -fpie builds don't default to hidden visibility for
> >symbol declarations as well as definitions.
>
> -ffreestanding doesn't mean there is no DSO. A libc implementation (e.g.
> musl) may use -ffreestanding to avoid libc dependencies from the host
> environment. It may ship several shared objects and export multiple symbols.
> Implied -fvisibility=hidden will get in the way.
>
> There is a merit to make options orthogonal.
Fair enough.
_______________________________________________
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:[~2022-04-29 7:29 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-27 17:12 [RFC PATCH 0/2] arm64: use PIE code generation for KASLR kernel Ard Biesheuvel
2022-04-27 17:12 ` [RFC PATCH 1/2] arm64: jump_label: use more precise asm constraints Ard Biesheuvel
2022-04-27 18:58 ` Nick Desaulniers
2022-04-27 21:50 ` Ard Biesheuvel
2022-04-28 9:35 ` Ard Biesheuvel
2022-04-28 9:51 ` Mark Rutland
2022-04-28 16:05 ` Ard Biesheuvel
2022-04-27 17:12 ` [RFC PATCH 2/2] arm64: kernel: switch to PIE code generation for relocatable kernels Ard Biesheuvel
2022-04-28 2:40 ` Fangrui Song
2022-04-28 6:23 ` Ard Biesheuvel
2022-04-28 6:57 ` Fangrui Song
2022-04-28 16:03 ` Ard Biesheuvel
2022-04-28 18:53 ` Nick Desaulniers
2022-04-28 19:36 ` Ard Biesheuvel
2022-04-29 7:03 ` Fangrui Song
2022-04-29 7:27 ` Ard Biesheuvel [this message]
2022-04-29 7:53 ` Fangrui Song
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='CAMj1kXHJb0EJPtQP1c=2X0eWg_6s0FyLqpqjauKbt5ktjhS9CA@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=clang-built-linux@googlegroups.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=maskray@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=samitolvanen@google.com \
--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
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).