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;
Feedback-ID: ieff94742:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-386-g2404815117-fm-20230425.001-g24048151
Mime-Version: 1.0
Message-Id: <44b21bb3-a65d-4560-9fe5-c7ddc260ddc0@app.fastmail.com>
In-Reply-To: <CAMj1kXH5+scbFuaOP+VC7EHEZcn-tmp3nk=9uYGYGfJyb0S92Q@mail.gmail.com>
References: <20230416120729.2470762-1-ardb@kernel.org>
 <5694ea5d-da9a-413e-9499-02a54588a953@app.fastmail.com>
 <CAMj1kXH5+scbFuaOP+VC7EHEZcn-tmp3nk=9uYGYGfJyb0S92Q@mail.gmail.com>
Date:   Wed, 03 May 2023 10:55:19 -0700
From:   "Andy Lutomirski" <luto@kernel.org>
To:     "Ard Biesheuvel" <ardb@kernel.org>
Cc:     linux-efi@vger.kernel.org,
        "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
        "Evgeniy Baskov" <baskov@ispras.ru>,
        "Borislav Petkov" <bp@alien8.de>,
        "Dave Hansen" <dave.hansen@linux.intel.com>,
        "Ingo Molnar" <mingo@redhat.com>,
        "Peter Zijlstra (Intel)" <peterz@infradead.org>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        "Alexey Khoroshilov" <khoroshilov@ispras.ru>,
        "Peter Jones" <pjones@redhat.com>,
        "Gerd Hoffmann" <kraxel@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>
Subject: Re: [RFC PATCH 0/3] efi: Implement generic zboot support
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Fri, Apr 21, 2023, at 6:41 AM, Ard Biesheuvel wrote:
> On Fri, 21 Apr 2023 at 15:30, Andy Lutomirski <luto@kernel.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 E=
FI
>> > 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=E2=80=
=99t dug into the code:
>>
>> Could zboot and bzImage be built into the same kernel image?  That wo=
uld get this into distros, and eventually someone could modify the legac=
y path to switch to long mode and invoke zboot (because zboot surely doe=
sn=E2=80=99t need actual UEFI =E2=80=94 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 s=
tuff has an allocator!  It's this:

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

plus a trivial and horrible malloc() implementation in include/linux/dec=
ompress/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 f=
lat 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 ba=
ck 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 tr=
ouble with a simple allocator.