From: Nathan Chancellor <nathan@kernel.org>
To: Brian Gerst <brgerst@gmail.com>
Cc: Ard Biesheuvel <ardb+git@google.com>,
linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
Kevin Loughlin <kevinloughlin@google.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Dionna Glaze <dionnaglaze@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Martin KaFai Lau <martin.lau@linux.dev>,
Nick Desaulniers <ndesaulniers@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-arch@vger.kernel.org, bpf@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [RFC PATCH 4/5] x86/head64: Replace pointer fixups with PIE codegen
Date: Mon, 22 Jan 2024 15:44:17 -0700 [thread overview]
Message-ID: <20240122224417.GC141255@dev-fedora.aadp> (raw)
In-Reply-To: <CAMzpN2jcWxCy=H-1uvS7kN8gVohee2_cMwyC0SbSEwEoedo3WQ@mail.gmail.com>
On Mon, Jan 22, 2024 at 02:34:46PM -0500, Brian Gerst wrote:
> On Mon, Jan 22, 2024 at 4:14 AM Ard Biesheuvel <ardb+git@google.com> wrote:
> >
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > Some of the C code in head64.c may be called from a different virtual
> > address than it was linked at. Currently, we deal with this by using
> > ordinary, position dependent codegen, and fixing up all symbol
> > references on the fly. This is fragile and tricky to maintain. It is
> > also unnecessary: we can use position independent codegen (with hidden
> > visibility) to ensure that all compiler generated symbol references are
> > RIP-relative, removing the need for fixups entirely.
> >
> > It does mean we need explicit references to kernel virtual addresses to
> > be generated by hand, so generate those using a movabs instruction in
> > inline asm in the handful places where we actually need this.
> >
> > While at it, move these routines to .inittext where they belong.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > arch/x86/Makefile | 11 ++
> > arch/x86/boot/compressed/Makefile | 2 +-
> > arch/x86/include/asm/init.h | 2 -
> > arch/x86/include/asm/setup.h | 2 +-
> > arch/x86/kernel/Makefile | 4 +
> > arch/x86/kernel/head64.c | 117 +++++++-------------
> > 6 files changed, 60 insertions(+), 78 deletions(-)
> >
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 1a068de12a56..bed0850d91b0 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -168,6 +168,17 @@ else
> > KBUILD_CFLAGS += -mcmodel=kernel
> > KBUILD_RUSTFLAGS += -Cno-redzone=y
> > KBUILD_RUSTFLAGS += -Ccode-model=kernel
> > +
> > + PIE_CFLAGS := -fpie -mcmodel=small \
> > + -include $(srctree)/include/linux/hidden.h
> > +
> > + ifeq ($(CONFIG_STACKPROTECTOR),y)
> > + ifeq ($(CONFIG_SMP),y)
> > + PIE_CFLAGS += -mstack-protector-guard-reg=gs
> > + endif
>
> This compiler flag requires GCC 8.1 or later. When I posted a patch
> series[1] to convert the stack protector to a normal percpu variable
> instead of the fixed offset, there was pushback over requiring GCC 8.1
> to keep stack protector support. I added code to objtool to convert
> code from older compilers, but there hasn't been any feedback since.
> Similar conversion code would be needed in objtool for this unless the
> decision is made to require GCC 8.1 for stack protector support going
> forward.
>
> Brian Gerst
>
> [1] https://lore.kernel.org/lkml/20231115173708.108316-1-brgerst@gmail.com/
I was going to comment on this as well, as that flag was only supported
in clang 12.0.0 and newer. It should not be too big of a deal for us
though, as I was already planning on bumping the minimum supported
version of clang for building the kernel to 13.0.1 (but there may be
breakage reports if this series lands before that):
https://lore.kernel.org/20240110165339.GA3105@dev-arch.thelio-3990X/
Cheers,
Nathan
next prev parent reply other threads:[~2024-01-22 22:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 9:08 [RFC PATCH 0/5] x86: Build the core kernel using PIC codegen Ard Biesheuvel
2024-01-22 9:08 ` [RFC PATCH 1/5] kallsyms: Avoid weak references for kallsyms symbols Ard Biesheuvel
2024-01-22 9:08 ` [RFC PATCH 2/5] vmlinux: Avoid weak reference to notes section Ard Biesheuvel
2024-01-22 9:08 ` [RFC PATCH 3/5] btf: Avoid weak external references Ard Biesheuvel
2024-01-22 9:08 ` [RFC PATCH 4/5] x86/head64: Replace pointer fixups with PIE codegen Ard Biesheuvel
2024-01-22 19:34 ` Brian Gerst
2024-01-22 22:44 ` Nathan Chancellor [this message]
2024-01-25 10:43 ` Ard Biesheuvel
2024-01-22 9:08 ` [RFC PATCH 5/5] x86: Build the core kernel with position independent codegen 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=20240122224417.GC141255@dev-fedora.aadp \
--to=nathan@kernel.org \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=justinstitt@google.com \
--cc=kevinloughlin@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=luto@kernel.org \
--cc=martin.lau@linux.dev \
--cc=mingo@redhat.com \
--cc=ndesaulniers@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
/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.