linux-efi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jan Hendrik Farr <kernel@jfarr.cc>
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 v2 00/15] x86/boot: Rework PE header generation
Date: Tue, 3 Oct 2023 04:02:54 +0200	[thread overview]
Message-ID: <ZRt2ToOHm2XT8MlU@desktop> (raw)
In-Reply-To: <20230912090051.4014114-17-ardb@google.com>

On 12 09:00:51, Ard Biesheuvel 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.

This split is also useful for the work of kexecing the next kernel as an
EFI application. With the current EFI stub I have to set the memory both
writable and executable which results in W^X warnings with a default
config.

What made this more confusing was that the flags of the .text section in
current EFI stub bzImages are set to
IMAGE_SCN_MEM_EXECUTE | IMAGE_SCN_MEM_READ. So if you load that section
according to those flags the EFI stub will quickly run into issues.

I assume current firmware on x86 machines does not set any restricted
permissions on the memory. Can someone enlighten me on their behavior?


> 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 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 (15):
>   x86/efi: Drop EFI stub .bss from .data section
>   x86/efi: Disregard setup header of loaded image
>   x86/efi: Drop alignment flags from PE section headers
>   x86/boot: Remove the 'bugger off' message
>   x86/boot: Omit compression buffer from PE/COFF image memory footprint
>   x86/boot: Drop redundant code setting the root device
>   x86/boot: Grab kernel_info offset from zoffset header directly
>   x86/boot: Drop references to startup_64
>   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  |   6 +-
>  arch/x86/boot/header.S                  | 213 ++++++---------
>  arch/x86/boot/setup.ld                  |  14 +-
>  arch/x86/boot/tools/build.c             | 273 +-------------------
>  drivers/firmware/efi/libstub/Makefile   |   7 -
>  drivers/firmware/efi/libstub/x86-stub.c |  46 +---
>  7 files changed, 114 insertions(+), 447 deletions(-)
> 
> -- 
> 2.42.0.283.g2d96d420d3-goog
> 

  parent reply	other threads:[~2023-10-03  2:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12  9:00 [PATCH v2 00/15] x86/boot: Rework PE header generation Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 01/15] x86/efi: Drop EFI stub .bss from .data section Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 02/15] x86/efi: Disregard setup header of loaded image Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 03/15] x86/efi: Drop alignment flags from PE section headers Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 04/15] x86/boot: Remove the 'bugger off' message Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 05/15] x86/boot: Omit compression buffer from PE/COFF image memory footprint Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 06/15] x86/boot: Drop redundant code setting the root device Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 07/15] x86/boot: Grab kernel_info offset from zoffset header directly Ard Biesheuvel
2023-09-12  9:00 ` [PATCH v2 08/15] x86/boot: Drop references to startup_64 Ard Biesheuvel
2023-09-15  9:15   ` Ingo Molnar
2023-09-15 13:48     ` Ard Biesheuvel
2023-09-15 15:40       ` Ingo Molnar
2023-09-15 15:45         ` Ingo Molnar
2023-09-15 15:48           ` Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 09/15] x86/boot: Set EFI handover offset directly in header asm Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 10/15] x86/boot: Define setup size in linker script Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 11/15] x86/boot: Derive file size from _edata symbol Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 12/15] x86/boot: Construct PE/COFF .text section from assembler Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 13/15] x86/boot: Drop PE/COFF .reloc section Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 14/15] x86/boot: Split off PE/COFF .data section Ard Biesheuvel
2023-09-12  9:01 ` [PATCH v2 15/15] x86/boot: Increase section and file alignment to 4k/512 Ard Biesheuvel
2023-09-15  9:22 ` [PATCH v2 00/15] x86/boot: Rework PE header generation Ingo Molnar
2023-09-15 11:30   ` Ingo Molnar
2023-09-15 13:21     ` Ard Biesheuvel
2023-09-15 13:28       ` Ard Biesheuvel
2023-09-16  9:10         ` Ingo Molnar
2023-09-16 19:14           ` Ard Biesheuvel
2023-09-17 17:50             ` Ingo Molnar
2023-10-03  2:02 ` Jan Hendrik Farr [this message]
2023-10-23 11:22   ` Ard Biesheuvel
2023-10-23 17:35     ` Jan Hendrik Farr
2023-10-24  8:21       ` Dave Young
2023-10-24  8:31         ` Dave Young

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=ZRt2ToOHm2XT8MlU@desktop \
    --to=kernel@jfarr.cc \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).