linux-kernel - Re: [RFC PATCH 0/3] efi: Implement generic zboot support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXH5+scbFuaOP+VC7EHEZcn-tmp3nk=9uYGYGfJyb0S92Q@mail.gmail.com>
Date:   Fri, 21 Apr 2023 15:41:08 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     linux-efi@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Evgeniy Baskov <baskov@...ras.ru>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        "Peter Zijlstra (Intel)" <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 Fri, 21 Apr 2023 at 15:30, Andy Lutomirski <luto@...nel.org> wrote:
>
>
>
> On Sun, Apr 16, 2023, at 5:07 AM, 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.
>
> I like the concept.  A couple high-level questions, since I haven’t dug into the code:
>
> Could zboot and bzImage be built into the same kernel image?  That would get this into distros, and eventually someone could modify the legacy path to switch to long mode and invoke zboot (because zboot surely doesn’t need actual UEFI — just a sensible environment like what UEFI provides.)
>

That's an interesting question, and to some extent, that is actually
what Evgeny's patch does: execute more of what the decompressor does
from inside the EFI runtime context.

The main win with zboot imho is that we get rid of all the funky
heuristics that look for usable memory for trampolines and
decompression buffers in funky ways, and instead, just use the EFI
APIs for allocating pages and remapping them executable as needed
(which is the important piece here) I'd have to think about whether
there is any middle ground between this approach and Evgeny's - I'll
have to get back to you on that.

> Does zboot set up BSS correctly?  I once went down a rabbit hole trying to get the old decompressor to jump into the kernel with BSS already usable and zeroed, and the result was an incredible mess — IIRC the decompressor does some in-place shenanigans that looked incompatible with handling BSS without a rewrite. And so we clear BSS in C after jumping to the kernel, which is gross.
>

Zboot pads the image to include BSS, so that the zboot metadata covers
the actual memory footprint of the image rather than just the image
size, and it will get zeroed out as a result of the decompression too,
which is a nice bonus. I did this mainly to try and make it idiot
proof for other (non-EFI) consumers of the zboot header and compressed
payload, but it means that the zboot EFI loader doesn't have to bother
either.