Re: [PATCH v7 22/22] x86/efistub: Avoid legacy decompressor when doing EFI boot

From: Ard Biesheuvel
Date: Wed Aug 02 2023 - 06:47:48 EST


On Wed, 2 Aug 2023 at 12:26, Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> On Fri, Jul 28, 2023 at 11:09:16AM +0200, Ard Biesheuvel wrote:
> > The bare metal decompressor code was never really intended to run in a
> > hosted environment such as the EFI boot services, and does a few things
> > that are problematic in the context of EFI boot now that the logo
> > requirements are getting tighter.
>
> Please spend a sentence or two explaining those. After some time has
> passed, no one will remember what that tightening of the requirements
> was.
>

OK. The next paragraph already covers this to some extent, but i'll
add some more prose here to clarify it further.

> So yeah, other than those minor nitpicks, I like the thing, all in all.
>

Good.

> Pls send v8 so that I can run it here on my machines. A git branch would
> be cool too.
>

OK

https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=x86-efistub-cleanup-v8

I'll prepare the v8 based on this branch after doing some more tests
on bare metal. I'll probably send it out later today.

> As to merging this, I presume you want it to go through tip?
>

It depends on the timing. If we take the whole thing now, it should
ideally go through -tip.

There is a conflict with the kexec sev patch you just suggested on the
list, though. I'll rebase onto that in any case, but if that causes
any problems, we might decide to take everything except the last two
(or three *) patches now, and defer those for later.

* 'efi/libstub: Add limit argument to efi_random_alloc()' may conflict
with some changes that may arrive via the RISC-V tree. That patch is
completely independent, so perhaps I should put it on a shared stable
branch in the EFI tree. Or alternatively, depending on how you decide
to organize the branches, you could put it at the beginning of the
topic branch where the RISC-V tree can merge it in.

Or we might just ignore the conflict - it just adds a function
argument to a function call that gets moved from one source file to
the another in the conflicting branch, so it should be rather
straight-forward to resolve.