All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	linux-kernel@vger.kernel.org, x86@kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Kees Cook <kees@kernel.org>, Uros Bizjak <ubizjak@gmail.com>,
	Brian Gerst <brgerst@gmail.com>,
	linux-hardening@vger.kernel.org
Subject: Re: [RFC/RFT PATCH 04/19] x86: Make the 64-bit bzImage always physically relocatable
Date: Mon, 12 Jan 2026 10:47:46 +0000	[thread overview]
Message-ID: <20260112104746.6521740c@pumpkin> (raw)
In-Reply-To: <3f2e8d7c-6029-49ef-8e31-a3eb5efb385b@zytor.com>

On Sun, 11 Jan 2026 20:01:02 -0800
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On 2026-01-08 01:25, Ard Biesheuvel wrote:
> > On x86_64, the physical placement of the kernel is independent from its
> > mapping in the 'High Kernel Mapping' range. This means that even a
> > position dependent kernel built without boot-time relocation support can
> > run from any suitably aligned physical address, and there is no need to
> > make this behavior dependent on whether or not the kernel is virtually
> > relocatable.
> > 
> > On i386, the situation is different, given that the physical and virtual
> > load offsets must be equal, and so only a relocatable kernel can be
> > loaded at a physical address that deviates from its build-time default.
> > 
> > Clarify this in Kconfig and in the code, and advertise the 64-bit
> > bzImage as loadable at any physical offset regardless of whether
> > CONFIG_RELOCATABLE is set. In practice, this makes little difference,
> > given that it defaults to 'y' and is a prerequisite for EFI_STUB and
> > RANDOMIZE_BASE, but it will help with some future refactoring of the
> > relocation code.
> >   
> 
> I don't see any reason to support non-relocatable kernels anymore. In fact, in
> a patchset I am working on I have already removed it.

For just 64bit, or 32bit as well?
The 'bloat' for 32bit will be higher due to the lack of pc-relative
addressing.

	David

> 
> 	-hpa
> 
> 


  reply	other threads:[~2026-01-12 10:47 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-08  9:25 [RFC/RFT PATCH 00/19] Link the relocatable x86 kernel as PIE Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 01/19] x86/idt: Move idt_table to __ro_after_init section Ard Biesheuvel
2026-01-22 13:08   ` Borislav Petkov
2026-01-22 13:48     ` Ard Biesheuvel
2026-01-22 13:58       ` Borislav Petkov
2026-01-22 14:09         ` Ard Biesheuvel
2026-01-22 14:16           ` Borislav Petkov
2026-01-22 14:20             ` Ard Biesheuvel
2026-01-22 14:25               ` Borislav Petkov
2026-01-08  9:25 ` [RFC/RFT PATCH 02/19] x86/sev: Don't emit BSS_DECRYPT section unless it is in use Ard Biesheuvel
2026-01-31 14:09   ` [tip: x86/sev] x86/sev: Don't emit BSS_DECRYPTED " tip-bot2 for Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 03/19] x86: Combine .data with .bss in kernel mapping Ard Biesheuvel
2026-03-06 19:07   ` Borislav Petkov
2026-03-09 14:11     ` Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 04/19] x86: Make the 64-bit bzImage always physically relocatable Ard Biesheuvel
2026-01-12  4:01   ` H. Peter Anvin
2026-01-12 10:47     ` David Laight [this message]
2026-01-12 12:06       ` H. Peter Anvin
2026-01-08  9:25 ` [RFC/RFT PATCH 05/19] x86/efistub: Simplify early remapping of kernel text Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 06/19] alloc_tag: Use __ prefixed ELF section names Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 07/19] tools/objtool: Treat indirect ftrace calls as direct calls Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 08/19] x86: Use PIE codegen for the relocatable 64-bit kernel Ard Biesheuvel
2026-01-09 21:34   ` Jan Engelhardt
2026-01-09 22:07     ` Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 09/19] x86/pm-trace: Use RIP-relative accesses for .tracedata Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 10/19] x86/kvm: Use RIP-relative addressing Ard Biesheuvel
2026-01-20 17:04   ` Sean Christopherson
2026-01-20 19:43     ` David Laight
2026-01-20 20:54       ` Ard Biesheuvel
2026-01-20 22:00         ` David Laight
2026-01-08  9:25 ` [RFC/RFT PATCH 11/19] x86/rethook: Use RIP-relative reference for fake return address Ard Biesheuvel
2026-01-08 12:08   ` David Laight
2026-01-08 12:10     ` Ard Biesheuvel
2026-01-08 12:19       ` Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 12/19] x86/sync_core: Use RIP-relative addressing Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 13/19] x86/entry_64: " Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 14/19] x86/hibernate: Prefer RIP-relative accesses Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 15/19] x64/acpi: Use PIC-compatible references in wakeup_64.S Ard Biesheuvel
2026-01-09  5:01   ` Brian Gerst
2026-01-09  7:59     ` Ard Biesheuvel
2026-01-09 11:46       ` Brian Gerst
2026-01-09 12:09         ` Ard Biesheuvel
2026-01-09 12:10           ` Ard Biesheuvel
2026-01-09 12:51             ` Brian Gerst
2026-01-08  9:25 ` [RFC/RFT PATCH 16/19] x86/kexec: Use 64-bit wide absolute reference from relocated code Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 17/19] x86/head64: Avoid absolute references in startup asm Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 18/19] x86/boot: Implement support for RELA/RELR/REL runtime relocations Ard Biesheuvel
2026-01-08  9:25 ` [RFC/RFT PATCH 19/19] x86/kernel: Switch to PIE linking for the relocatable kernel Ard Biesheuvel
2026-01-08 16:35 ` [RFC/RFT PATCH 00/19] Link the relocatable x86 kernel as PIE Alexander Lobakin
2026-01-09  0:36 ` H. Peter Anvin
2026-01-09  9:21   ` Ard Biesheuvel
2026-01-14 18:16     ` Kees Cook
2026-01-20 20:45       ` H. Peter Anvin
2026-01-21  8:56         ` 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=20260112104746.6521740c@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=brgerst@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@kernel.org \
    --cc=kees@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=ubizjak@gmail.com \
    --cc=x86@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 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.