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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <11e0aff9-0388-4a6c-8986-301d4edc482d@app.fastmail.com>
Date:   Wed, 13 Sep 2023 17:07:31 +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

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 can see how #4 is kinda tautological, but please don't dismiss the
other arguments without even responding.

> 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?

No, not every single feature of *UKI*s exist in the linux kernel today.

> 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.

Again for #4 I see the point, but what about #1 , and #3 (#2 is not that
important, tooling can be fixed)? Also, do you see how your argument is
basically: "The current way is better because it is the current way."
I'm not trying to be snarky. But I'm coming from the perspective of a
user that actually experienced a problem (not being able to kexec my
UKIs) and trying to come up with a fix. I'm not trying to push something
for the heck of it.

Also the UKI spec at this point is not ready for the kernel, so this is
not going in anyways right now. See the discussion on v2:
https://lore.kernel.org/kexec/ZP+41JvEFjsnEG19@MiWiFi-R3L-srv/T/#t