lkml.org 
[lkml]   [2023]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v3 0/8] x86/boot: Rework PE header generation

    * 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

    \
     
     \ /
      Last update: 2023-09-17 19:52    [W:2.165 / U:0.068 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site