linux-kernel - Re: [PATCH v2 0/2] 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]

Message-Id: <0e1984af-88ca-4908-a5ca-3191d96aa63f@app.fastmail.com>
Date:   Thu, 14 Sep 2023 23:04:32 +0200
From:   "Jan Hendrik Farr" <kernel@...rr.cc>
To:     "Philipp Rudo" <prudo@...hat.com>,
        "Lennart Poettering" <mzxreary@...inter.de>
Cc:     linux-kernel@...r.kernel.org, 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, "Luca Boccassi" <bluca@...ian.org>
Subject: Re: [PATCH v2 0/2] x86/kexec: UKI Support

On Thu, Sep 14, 2023, at 8:51 PM, Philipp Rudo wrote:
> [...]
>
> In this context I hope it is also clear to you that when more and more
> people rely on the spec you need a more formal process when including
> changes. Especially when the change might break the implementation of
> others. So no more making the .cmdline optional and allowing it to be
> overwritten all on the same day.
>
> Having that said, what does "local override" exactly mean? Does that
> mean a distro can allow a user to freely choose the cmdline without
> checking any signatures?

The behavior of systemd-stub is to allow the bootloader (or whatever
called sd-stub) supplied cmdline when there is no .cmdline section in
the UKI. That's how I understand "local override" here. For WIP v3 of
this patch the behavior is to use the cmdline supplied by userspace to
the kexec_file_load syscall if no .cmdline section is in the UKI.

empty .cmdline section -> empty cmdline always passed to kernel
.cmdline section -> use bootloader/user supplied cmdline (which would
be empty by default)

This setup does not make sense for a locked down / secure system though.

Maybe the word "override" is not ideal. There is nothing actually being
overridden as there is no cmdline in the UKI in the first place.

sd-stub also allows the bootloader supplied cmdline if not using secure
boot. So maybe the kernel could allow user supplied cmdline if not in
lockdown mode for kexec maybe? If not in lockdown mode somebody can just
kexec an unsigned kernel + unsigned cmdline using the kexec_load syscall
anyways. For this case the word "override" makes sense.

The logic for all of this in sd-stub is in [1].

> I.e. does that mean we can get rid of this
>      https://github.com/systemd/systemd/issues/24539

This is a different usecase IMO.

>> Hence, seeing the spec as set in stone and as inherently low quality
>> is the wrong way to see it I am sure. Instead, the goal here is to
>> adjust the spec to make it work really nicely for *both* systemd and
>> the kernel.
>
> Sorry, I never wanted to intend that the spec inherently low quality.
> Just that it doesn't meat my expectations, yet. But that is fine. The
> spec isn't even a year old and there's only a single implementation,
> yet. So it's more documentation rather than a spec.

Let's make it happen.

[1] https://github.com/systemd/systemd/blob/5898cef22a35ceefa068d5f46929eced2baab0ed/src/boot/efi/stub.c#L140