From: Ingo Molnar <mingo@kernel.org>
To: Ard Biesheuvel <ardb@google.com>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Ard Biesheuvel <ardb@kernel.org>,
Evgeniy Baskov <baskov@ispras.ru>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Jones <pjones@redhat.com>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Gerd Hoffmann <kraxel@redhat.com>,
Kees Cook <keescook@chromium.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v3 0/8] x86/boot: Rework PE header generation
Date: Sun, 17 Sep 2023 19:50:49 +0200 [thread overview]
Message-ID: <ZQc8efDzNs8gnv6X@gmail.com> (raw)
In-Reply-To: <20230915171623.655440-10-ardb@google.com>
* Ard Biesheuvel <ardb@google.com> wrote:
> From: Ard Biesheuvel <ardb@kernel.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@ispras.ru>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Peter Jones <pjones@redhat.com>
> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: "H. Peter Anvin" <hpa@zytor.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(-)
Applied to tip:x86/boot, thanks!
Ingo
prev parent reply other threads:[~2023-09-17 17:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-15 17:16 [PATCH v3 0/8] x86/boot: Rework PE header generation Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 1/8] x86/boot: Grab kernel_info offset from zoffset header directly Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 2/8] x86/boot: Set EFI handover offset directly in header asm Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 3/8] x86/boot: Define setup size in linker script Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 4/8] x86/boot: Derive file size from _edata symbol Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 5/8] x86/boot: Construct PE/COFF .text section from assembler Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 6/8] x86/boot: Drop PE/COFF .reloc section Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 7/8] x86/boot: Split off PE/COFF .data section Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-15 17:16 ` [PATCH v3 8/8] x86/boot: Increase section and file alignment to 4k/512 Ard Biesheuvel
2023-09-17 18:12 ` [tip: x86/boot] " tip-bot2 for Ard Biesheuvel
2023-09-17 17:50 ` Ingo Molnar [this message]
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=ZQc8efDzNs8gnv6X@gmail.com \
--to=mingo@kernel.org \
--cc=ardb@google.com \
--cc=ardb@kernel.org \
--cc=baskov@ispras.ru \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kraxel@redhat.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=pjones@redhat.com \
--cc=tglx@linutronix.de \
/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.