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: <44b21bb3-a65d-4560-9fe5-c7ddc260ddc0@app.fastmail.com>
Date:   Wed, 03 May 2023 10:55:19 -0700
From:   "Andy Lutomirski" <luto@...nel.org>
To:     "Ard Biesheuvel" <ardb@...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, Apr 21, 2023, at 6:41 AM, Ard Biesheuvel wrote:
> 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.
>

Hmm.  I dug the tiniest bit into the history.  The x86/boot/compressed stuff has an allocator!  It's this:

        free_mem_ptr     = heap;        /* Heap */
        free_mem_end_ptr = heap + BOOT_HEAP_SIZE;

plus a trivial and horrible malloc() implementation in include/linux/decompress/mm.h.  There's one caller in x86/boot/compressed.

And, once upon a time, the idea of allocating enough memory to store the kernel from the decompressor would have been a problem.  I'm willing to claim that we should not even try to support x86 systems that have that little memory (at least not once they've gotten long mode or at least flat 32-bit protected mode working).  We should not try to allocate below 1MB (my laptop will cry), but there's no need for that.

So maybe the middle ground is to build a modern, simple malloc(), and back it by EFI when EFI is there and by just finding some free memory when EFI is not there?

This would be risky -- someone might have a horrible machine that has trouble with a simple allocator.