[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CVHVCHYZT8KG.3L0IH30QYT0WH@suppilovahvero>
Date: Wed, 13 Sep 2023 17:45:10 +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 11:49 PM EEST, Jan Hendrik Farr wrote:
>
> > 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).
>
> I think I misunderstood you in my earlier reply. I do not understand
> in what way you think my arguments are tautological. Can you
> elaborate?
current Linux kernel has these features *already* in
place:
1. CONFIG_EFI_STUB
2. CONFIG_CMDLINE
3. CONFIG_INITRAMFS_SOURCE
4. Secure boot with MOK keys and .machine keyring to manage them.
Given that every single feature in IKU does exists in some form
in the Linux kernel, I think it is fair to ask why scrape away
this all existing science and reinvent the wheel?
If your reponse is "systemd", it is a tautological answerk, i.e.
same as sayig that "it is good because it is good". Not very
motivating.
BR, Jarkko
Powered by blists - more mailing lists