From: Borislav Petkov <bp@alien8.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Ard Biesheuvel <ardb+git@google.com>,
linux-kernel@vger.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>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Justin Stitt <justinstitt@google.com>,
Kees Cook <keescook@chromium.org>,
Brian Gerst <brgerst@gmail.com>,
linux-arch@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v3 08/19] x86/head64: Replace pointer fixups with PIE codegen
Date: Mon, 12 Feb 2024 15:18:15 +0100 [thread overview]
Message-ID: <20240212141815.GDZcoop-AL-a6kiHcY@fat_crate.local> (raw)
In-Reply-To: <CAMj1kXH2uwLT-EgqYFRcC0OH524W=sYtDoFC-x+isifzsia17w@mail.gmail.com>
On Mon, Feb 12, 2024 at 12:52:01PM +0100, Ard Biesheuvel wrote:
> Yeah. That would means adding PIE_CFLAGS_REMOVE alongside PIE_CFLAGS
> and applying both in every place it is used, but we are only dealing
> with a handful of object files here.
Right.
And we already have such a thing with PURGATORY_CFLAGS_REMOVE.
> Thanks. But now that we have RIP_REL_REF(), I might split the cleanup
> from the actual switch to -fpie, which I am still a bit on the fence
> about, given different compiler versions, LTO, etc.
Tell me about it. Considering how much jumping through hoops we had to
do in recent years to accomodate building the source with the different
compilers, I'm all for being very conservative here.
> RIP_REL_REF(foo) just turns into 'foo' when compiling with -fpie and
> we could drop those piecemeal once we are confident that -fpie does
> not cause any regressions.
Ack.
> Note that I have some reservations now about .pi.text as well: it is a
> bit intrusive, and on x86, we might just as well move everything that
> executes from the 1:1 mapping into .head.text, and teach objtool that
> those sections should not contain any ELF relocations involving
> absolute addresses. But this is another thing that I want to spend a
> bit more time on before I respin it, so I will just do the cleanup in
> the next revision, and add the rigid correctness checks the next
> cycle.
I am fully onboard with being conservative and doing things in small
steps considering how many bugs tend to fall out when the stuff hits
upstream. So going slowly and making sure our sanity is intact is a very
good idea!
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2024-02-12 14:18 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 18:05 [PATCH v3 00/19] x86: Confine early 1:1 mapped startup code Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 01/19] efi/libstub: Add generic support for parsing mem_encrypt= Ard Biesheuvel
2024-01-31 7:31 ` Borislav Petkov
2024-02-01 16:23 ` Kevin Loughlin
2024-02-01 16:28 ` Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 02/19] x86/boot: Move mem_encrypt= parsing to the decompressor Ard Biesheuvel
2024-01-31 8:35 ` Borislav Petkov
2024-01-31 9:12 ` Ard Biesheuvel
2024-01-31 9:29 ` Borislav Petkov
2024-01-31 9:59 ` Ard Biesheuvel
2024-02-01 14:17 ` Tom Lendacky
2024-02-01 16:15 ` Ard Biesheuvel
2024-02-02 16:35 ` [PATCH] x86/Kconfig: Remove CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT Borislav Petkov
2024-02-02 16:47 ` Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 03/19] x86/startup_64: Drop long return to initial_code pointer Ard Biesheuvel
2024-01-31 13:44 ` Borislav Petkov
2024-01-31 13:57 ` Ard Biesheuvel
2024-01-31 14:07 ` Ard Biesheuvel
2024-01-31 16:29 ` Borislav Petkov
2024-01-29 18:05 ` [PATCH v3 04/19] x86/startup_64: Simplify calculation of initial page table address Ard Biesheuvel
2024-02-05 10:40 ` Borislav Petkov
2024-01-29 18:05 ` [PATCH v3 05/19] x86/startup_64: Simplify CR4 handling in startup code Ard Biesheuvel
2024-02-06 18:21 ` Borislav Petkov
2024-02-07 10:38 ` Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 06/19] x86/startup_64: Drop global variables keeping track of LA57 state Ard Biesheuvel
2024-02-07 13:29 ` Borislav Petkov
2024-02-09 13:55 ` Ard Biesheuvel
2024-02-10 10:40 ` Borislav Petkov
2024-02-11 22:36 ` Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 07/19] x86/startup_64: Simplify virtual switch on primary boot Ard Biesheuvel
2024-02-07 14:50 ` Borislav Petkov
2024-01-29 18:05 ` [PATCH v3 08/19] x86/head64: Replace pointer fixups with PIE codegen Ard Biesheuvel
2024-02-12 10:29 ` Borislav Petkov
2024-02-12 11:52 ` Ard Biesheuvel
2024-02-12 14:18 ` Borislav Petkov [this message]
2024-01-29 18:05 ` [PATCH v3 09/19] x86/head64: Simplify GDT/IDT initialization code Ard Biesheuvel
2024-02-12 14:37 ` Borislav Petkov
2024-02-12 15:23 ` Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 10/19] asm-generic: Add special .pi.text section for position independent code Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 11/19] x86: Move return_thunk to __pitext section Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 12/19] x86/head64: Move early startup code into __pitext Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 13/19] modpost: Warn about calls from __pitext into other text sections Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 14/19] x86/coco: Make cc_set_mask() static inline Ard Biesheuvel
2024-01-30 23:16 ` Kevin Loughlin
2024-01-30 23:36 ` Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 15/19] x86/sev: Make all code reachable from 1:1 mapping __pitext Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 16/19] x86/sev: Avoid WARN() in early code Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 17/19] x86/sev: Use PIC codegen for early SEV startup code Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 18/19] x86/sev: Drop inline asm LEA instructions for RIP-relative references Ard Biesheuvel
2024-01-29 18:05 ` [PATCH v3 19/19] x86/startup_64: Don't bother setting up GS before the kernel is mapped 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=20240212141815.GDZcoop-AL-a6kiHcY@fat_crate.local \
--to=bp@alien8.de \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=dionnaglaze@google.com \
--cc=justinstitt@google.com \
--cc=keescook@chromium.org \
--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=mingo@redhat.com \
--cc=nathan@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox