linux-kernel - Re: [PATCH 0/1] x86/kexec: UKI 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]

Date:   Tue, 12 Sep 2023 21:38:59 +0200
From:   "Jan Hendrik Farr" <kernel@...rr.cc>
To:     "Jarkko Sakkinen" <jarkko@...nel.org>, 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

> These are sort of "tautological" arguments. There must be some
> objective reasons why this architecture was chosen instead of
> other (i.e. using what already pre-exists).

You mean like your argument that the same can already be achieved with the normal EFI stub and builin initrd/cmdline? ;)

I think only reasons #4 and the last paragraph in me response relate to it being pre-existing. The other reasons are actual limitations with the normal EFI stub setup. Doesn't mean that they can't be overcome, but UKIs work.

I'm not sure what the initial reasons where for coming up with this architecture were, I was not involved.

What I can tell you is that right now it is a format that has practical advantages and that there are generic mainstream distros looking to adopt it. So having the capability to kexec them is gonna come in handy.