Message-ID: <620de8eecdc255f11313bb96e32b5b89@ispras.ru>
Date:   Tue, 18 Apr 2023 17:10:37 +0300
From:   Evgeniy Baskov <baskov@...ras.ru>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexey Khoroshilov <khoroshilov@...ras.ru>,
        Peter Jones <pjones@...hat.com>,
        Gerd Hoffmann <kraxel@...hat.com>,
        Dave Young <dyoung@...hat.com>,
        Mario Limonciello <mario.limonciello@....com>,
        Kees Cook <keescook@...omium.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/3] efi: Implement generic zboot support

On 2023-04-16 15:07, Ard Biesheuvel wrote:
> This series is a proof-of-concept that implements support for the EFI
> zboot decompressor for x86. It replaces the ordinary decompressor, and
> instead, performs the decompression, KASLR randomization and the 4/5
> level paging switch while running in the execution context of EFI.
> 
> This simplifies things substantially, and makes it straight-forward to
> abide by stricter future requirements related to the use of writable 
> and
> executable memory under EFI, which will come into effect on x86 systems
> that are certified as being 'more secure', and ship with an even 
> shinier
> Windows sticker.
> 
> This is an alternative approach to the work being proposed by Evgeny 
> [0]
> that makes rather radical changes to the existing decompressor, which
> has accumulated too many features already, e.g., related to 
> confidential
> compute etc.
> 
> EFI zboot images can be booted in two ways:
> - by EFI firmware, which loads and starts it as an ordinary EFI
>   application, just like the existing EFI stub (with which it shares
>   most of its code);
> - by a non-EFI loader that parses the image header for the compression
>   metadata, and decompresses the image into memory and boots it.
> 
> Realistically, the second option is unlikely to ever be used on x86,
> given that it already has its existing bzImage, but the first option is
> a good choice for distros that target EFI boot only (and some distros
> switched to this format already for arm64). The fact that EFI zboot is
> implemented in the same way on arm64, RISC-V, LoongArch and [shortly]
> ARM helps with maintenance, not only of the kernel itself, but also the
> tooling around it relating to kexec, code signing, deployment, etc.
> 
> Series can be pulled from [1], which contains some prerequisite patches
> that are only tangentially related.

I've considered using similar approach when I was writing my series.
That looks great if you look at subject without considering backwards
compatibility, especially due to the increased code sharing and the 
usage
of the code path without all the legacy stuff. But, I think, that zboot
approach have two downsides:

* Most distros won't use it, due to backward compatibility, so they 
won't
   benefit the improvements.
* Those distros that would potentially use it, have to be either
   DIY-ish like Gentoo, or provide both kernels during installation.
   So it either complicates installation process or installer logic.

It might work for UEFI-only distros, but those won't be a majority for a
little while for x86, I think. Because it's very likely that a lot of 
people
will complain if distro provides zboot-only kernel (considering that the
same story with the handover protocol). Backward compatibility is evil.

So, I think, at least for now, it would still be better to change 
existing
extraction code and stay compatible, despite it being harder and less 
clean...

(zboot also lacks the support for some kernel options, like ones used 
for
tweaking memory map; mixed mode support and probably the handling of
CONFIG_MEMORY_HOTREMOVE, but that's an RFC, so this comment is largely
irrelevant for now.)

Thanks,
Evgeniy Baskov

> 
> [0] https://lore.kernel.org/all/cover.1678785672.git.baskov@ispras.ru/
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=efi-x86-zboot
> 
> Cc: Evgeniy Baskov <baskov@...ras.ru>
> Cc: Borislav Petkov <bp@...en8.de>
> Cc: Andy Lutomirski <luto@...nel.org>
> Cc: Dave Hansen <dave.hansen@...ux.intel.com>
> Cc: Ingo Molnar <mingo@...hat.com>
> Cc: Peter Zijlstra <peterz@...radead.org>
> Cc: Thomas Gleixner <tglx@...utronix.de>
> Cc: Alexey Khoroshilov <khoroshilov@...ras.ru>
> Cc: Peter Jones <pjones@...hat.com>
> Cc: Gerd Hoffmann <kraxel@...hat.com>
> Cc: Dave Young <dyoung@...hat.com>
> Cc: Mario Limonciello <mario.limonciello@....com>
> Cc: Kees Cook <keescook@...omium.org>
> Cc: Tom Lendacky <thomas.lendacky@....com>
> Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> 
> Ard Biesheuvel (3):
>   efi/libstub: x86: Split off pieces shared with zboot
>   efi/zboot: x86: Implement EFI zboot support
>   efi/zboot: x86: Clear NX restrictions on populated code regions
> 
>  arch/x86/Makefile                              |  18 +-
>  arch/x86/include/asm/efi.h                     |  10 +
>  arch/x86/kernel/head_64.S                      |  15 +
>  arch/x86/zboot/Makefile                        |  29 +
>  drivers/firmware/efi/Kconfig                   |   2 +-
>  drivers/firmware/efi/libstub/Makefile          |  15 +-
>  drivers/firmware/efi/libstub/Makefile.zboot    |   2 +-
>  drivers/firmware/efi/libstub/efi-stub-helper.c |   3 +
>  drivers/firmware/efi/libstub/x86-stub.c        | 592 
> +------------------
>  drivers/firmware/efi/libstub/x86-zboot.c       | 322 ++++++++++
>  drivers/firmware/efi/libstub/x86.c             | 612 
> ++++++++++++++++++++
>  drivers/firmware/efi/libstub/zboot.c           |   3 +-
>  drivers/firmware/efi/libstub/zboot.lds         |   5 +
>  13 files changed, 1031 insertions(+), 597 deletions(-)
>  create mode 100644 arch/x86/zboot/Makefile
>  create mode 100644 drivers/firmware/efi/libstub/x86-zboot.c
>  create mode 100644 drivers/firmware/efi/libstub/x86.c

Powered by blists - more mailing lists