[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CVHWWXJJLNO5.25DGTKFOPD35Y@suppilovahvero>
Date: Wed, 13 Sep 2023 18:58:53 +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 Wed Sep 13, 2023 at 6:07 PM EEST, Jan Hendrik Farr wrote:
> On Wed, Sep 13, 2023, at 4:45 PM, Jarkko Sakkinen wrote:
> > 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.
>
> Well, you also have to add
> 5. CONFIG_CMDLINE_OVERRIDE
> 6. CONFIG_INITRAMFS_FORCE
>
> Otherwise the bootloader can supply an unsinged initramfs/cmdline and
> the kernel will use them.
>
> And then you do not get all the features. One of your earlier responses
> asks how a user might change the cmdline with UKIs. With UKIs all they
> have to do is create a small addon file and sign that (with their MOK if
> they are using a generic distro with shim, instead of using their own
> secure boot keys). With the bzImage alternative they would have to
> recompile the kernel. This was reason #1.
>
> Also what about #3? How would you pass PCR signatures using the normal
> EFI stub / bzImage?
I did not notice anything in the description about PCRs but this
counter-question does really enlighten what I've been trying to say. You
should take time to explain where's the gain, and why it makes sense for
the users.
It does not really make sense for me to "defend" anything if I'm against
something that I don't understand what it is and is capable of and such
and so forth. I don't really care if e.g. systemd is using it, if it
does not make me understand the topic better. It is then just argument
by authority, which not a real argument in the first place.
Linking URL to the specification is good enough for *details* but it
does not save you from trouble of painting the picture what we are
looking at.
BR, Jarkko
Powered by blists - more mailing lists