Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230416120729.2470762-1-ardb@kernel.org> <jwvybt4sro56aiqvddn6jxdjpdelasdhl747c25kzv4vbjr7ph@fbtheokrtxce>
In-Reply-To: <jwvybt4sro56aiqvddn6jxdjpdelasdhl747c25kzv4vbjr7ph@fbtheokrtxce>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 19 Apr 2023 16:44:44 +0200
Message-ID: <CAMj1kXE4xF9RJbaR0H6uuFxxroUJxQFo8WThb=SUa7H0OpDxUg@mail.gmail.com>
Subject: Re: [RFC PATCH 0/3] efi: Implement generic zboot support
To:     Gerd Hoffmann <kraxel@redhat.com>
Cc:     linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
        Evgeniy Baskov <baskov@ispras.ru>,
        Borislav Petkov <bp@alien8.de>,
        Andy Lutomirski <luto@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Alexey Khoroshilov <khoroshilov@ispras.ru>,
        Peter Jones <pjones@redhat.com>,
        Dave Young <dyoung@redhat.com>,
        Mario Limonciello <mario.limonciello@amd.com>,
        Kees Cook <keescook@chromium.org>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 19 Apr 2023 at 07:54, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> On Sun, Apr 16, 2023 at 02:07:26PM +0200, 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.
>
> I like the idea to have all EFI archs handle compressed kernels the same
> way.
>
> But given that going EFI-only on x86 isn't a realistic option for
> distros today this isn't really an alternative for Evgeny's patch
> series, we have to fix the existing bzImage decompressor too.
>

I tend to agree, although some clarification would be helpful
regarding what is being fixed and why? I *think* I know, but I have
not been involved as deeply as some of the distro folks in getting
these requirements explicit.

> Realistically, the second option is unlikely to ever be used on x86,
>
> What would be needed to do so?  Teach kexec-tools and grub2 parse and
> load zboot kernels I guess?
>

I already implemented this for mach-virt here, so we can load Fedora
kernels without firmware:

https://gitlab.com/qemu-project/qemu/-/commit/ff11422804cd03494cc98691eecd3909ea09ab6f

On arm64, this is probably more straight-forward, as the bare metal
image is already intended to be booted directly like that. However,
the x86 uncompressed image requires surprisingly little from all the
boot_params/setup_header cruft to actually boot, so perhaps there it
is easy too.

There is an unresolved issue related to kexec_load_file(), where only
the compressed image is signed, but the uncompressed image is what
ultimately gets booted, which either needs the decompression to occur
in the kernel, or a secondary signature that the kernel can verify
after the decompression happens in user space.

Dave and I have generated several ideas here, but there hasn't been
any progress towards a solution that seems palatable for upstream.