[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230915171623.655440-10-ardb@google.com>
Date: Fri, 15 Sep 2023 17:16:24 +0000
From: Ard Biesheuvel <ardb@...gle.com>
To: linux-efi@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
Evgeniy Baskov <baskov@...ras.ru>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Jones <pjones@...hat.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Gerd Hoffmann <kraxel@...hat.com>,
Kees Cook <keescook@...omium.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: [PATCH v3 0/8] x86/boot: Rework PE header generation
From: Ard Biesheuvel <ardb@...nel.org>
Now that the EFI stub boot flow no longer relies on memory that is
executable and writable at the same time, we can reorganize the PE/COFF
view of the kernel image and expose the decompressor binary's code and
r/o data as a .text section and data/bss as a .data section, using 4k
alignment and limited permissions.
Doing so is necessary for compatibility with hardening measures that are
being rolled out on x86 PCs built to run Windows (i.e., the majority of
them). The EFI boot environment that the Linux EFI stub executes in is
especially sensitive to safety issues, given that a vulnerability in the
loader of one OS can be abused to attack another.
In true x86 fashion, this is a lot more complicated than on other
architectures, which have implemented this code/data split with 4k
alignment from the beginning. The complicating factor here is that the
boot image consists of two different parts, which are stitched together
and fixed up using a special build tool.
After this series is applied, the only remaining task performed by the
build tool is generating the CRC-32. Even though this checksum is
usually wrong (given that distro kernels are signed for secure boot in a
way that corrupts the CRC), this feature is retained as we cannot be
sure that nobody is relying on this.
This supersedes the work proposed by Evgeniy last year, which did a
major rewrite of the build tool in order to clean it up, before updating
it to generate the new 4k aligned image layout. As this series proves,
the build tool is mostly unnecessary, and we have too many of those
already.
Changes since v2:
- rebase onto tip/master
- drop patches that have been picked up already
- fix issue in the linker script that resulted in a bogus setup_size in
some cases when using ld.bfd
- fix comment capitalization
Changes since v1:
- drop patch that removed the CRC and the build tool
- do not use fixed setup_size but derive it in the setup.ld linker
script
- reorganize the PE header so the .compat section only covers its
payload and the padding that follows it
- add hpa's ack to patch #4
Cc: Evgeniy Baskov <baskov@...ras.ru>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Peter Jones <pjones@...hat.com>
Cc: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Gerd Hoffmann <kraxel@...hat.com>
Cc: Kees Cook <keescook@...omium.org>
Cc: "H. Peter Anvin" <hpa@...or.com>
Ard Biesheuvel (8):
x86/boot: Grab kernel_info offset from zoffset header directly
x86/boot: Set EFI handover offset directly in header asm
x86/boot: Define setup size in linker script
x86/boot: Derive file size from _edata symbol
x86/boot: Construct PE/COFF .text section from assembler
x86/boot: Drop PE/COFF .reloc section
x86/boot: Split off PE/COFF .data section
x86/boot: Increase section and file alignment to 4k/512
arch/x86/boot/Makefile | 2 +-
arch/x86/boot/compressed/vmlinux.lds.S | 5 +-
arch/x86/boot/header.S | 146 +++++++------
arch/x86/boot/setup.ld | 7 +-
arch/x86/boot/tools/build.c | 223 +-------------------
5 files changed, 97 insertions(+), 286 deletions(-)
--
2.42.0.459.ge4e396fd5e-goog
Powered by blists - more mailing lists