[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CVH4GZXQFZ1F.2V5BIZNSKQ1FA@suppilovahvero>
Date: Tue, 12 Sep 2023 20:41:33 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Jan Hendrik Farr" <kernel@...rr.cc>,
<linux-kernel@...r.kernel.org>
Cc: <kexec@...ts.infradead.org>, <x86@...nel.org>,
<tglx@...utronix.de>, <dhowells@...hat.com>, <vgoyal@...hat.com>,
<keyrings@...r.kernel.org>, <akpm@...ux-foundation.org>,
"Baoquan He" <bhe@...hat.com>, <bhelgaas@...gle.com>,
<lennart@...ttering.net>, "Luca Boccassi" <bluca@...ian.org>
Subject: Re: [PATCH 0/1] x86/kexec: UKI support
On Tue Sep 12, 2023 at 6:32 PM EEST, Jan Hendrik Farr wrote:
> >> The format itself is rather simple. It's just a PE file (as required
> >> by the UEFI spec) that contains a small stub application in the .text,
> >> .data, etc sections that is responsible for invoking the contained
> >> kernel and initrd with the contained cmdline. The kernel image is
> >> placed into a .kernel section, the initrd into a .initrd section, and
> >> the cmdline into a .cmdline section in the PE executable.
> >
> > How does this interact with the existing EFI stub support in linux?
>
> It doesn't. During normal boot of a UKI the stub in it is used
> (systemd-stub, see:
> https://www.freedesktop.org/software/systemd/man/systemd-stub.html).
> The kernel's own EFI stub will still be in the binary inside the
> .linux section but not used.
What sort of bottleneck does the EFI stub have so that we need yet
another envelope?
BR, Jarkko
Powered by blists - more mailing lists