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: <5a67051d-eb21-4a96-acc4-40f829a59e23@app.fastmail.com>
Date:   Tue, 12 Sep 2023 20:56:57 +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

> What sort of bottleneck does the EFI stub have so that we need yet
> another envelope?

Well I can come up with a few advantages of UKI compared to normal bzImage with builtin initrd and cmdline.

1. You already identified this one. Using addons to adjust your cmdline
2. I can use my normal initramfs generation tooling. Just install my compiled kernel, my distros install script will generate the initramfs. Then I package it up as a UKI. This will be a lot more awkward with a builtin initrd.
3. Measured boot. You can place PCR signatures in the UKI using systemd-measure. This will sign the expected PCR values for booting this UKI. I think with normal bzImage this will be a lot more difficult. If you place those PCR signatures in the builtin initrd this will change the kernel image which means now the values you signed no longer match (depending on how you measure the kernel; I don't think the normal EFI stub even measures the kernel in first place, but I could be mistaken about this)
4. UKIs are automatically recognized by systemd-boot

There's probably more reasons. The main reason for me to go with UKIs initially was the good tooling around them.

You could probably overcome some of these drawbacks in the default kernel EFI stub. For example it could also get a place to put signed PCR values. And it could also do TPM measurements. However in the process all you're doing is rebuilding what already exists today in systemd-stub and the tooling around UKIs.