We forgot to conditionalize this on pcrsig/pcrpkey too. So if you have
ne creds or sysext configured we actually wouldn't pass pcrsig/pcrpkey
along. Let's fix that.
Let's separate the PE section options in the --help text to make clearer
that they are about PE sections, and thus make things less confusing
regarding the cryptic names. Specifically, there's now a separate
section in the --help text that looks like this:
<snip>
UKI PE Section Options: UKI PE Section
--linux=PATH Path Linux kernel image → .linux
--osrel=PATH Path to os-release file → .osrel
--cmdline=PATH Path to file with kernel command line → .cmdline
--initrd=PATH Path to initrd image → .initrd
--splash=PATH Path to splash bitmap → .splash
--dtb=PATH Path to Devicetree file → .dtb
--pcrpkey=PATH Path to public key for PCR signatures → .pcrpkey
</snipe>
(The section title is underlined, like we usually do it)
I think separating this out, and organizing the section name in tabular
form emphasizes nicely where this switches get their name from and what
they mean.
Hopefully addresses concerns from
https://github.com/systemd/systemd/pull/24458#discussion_r967052720 in a
diferent way.
(Also dropped a hint regarding DER format for public key. it's simply
wrong, we use PEM like everyone else on Linux. Outside of Java land DER
isn't popular, so we don't need to mention it here in the --help text,
man page should be enough.)
The kernel PE image version can be used to detect support for this
feature, allowing us to prefer the generic code of the deprecated EFI
handover protocol.
We could try to relocate these but that is probably not needed. So far
we have not been bitten by this in the real world and kernels we boot
likely already support this anyway.
The boot params passed to the kernel only has to be one page in size
and the size of the setup header has to be calculated as it depends on
the boot protocol version supported by the kernel.
The kernel x86 boot protocol does not expect this value to be set when
using EFI handover protocol. If the stub is loaded above 4G we would
end up discarding the high bits, breaking boot.
Fixes: #24707
This way we can use it directly in measure.c, and thus remove a bit of
redundant code.
OpenSSL prefers uppercasing the MD names, others don't hence let's be
lenient here.
Let's say what we actually measure, not what into (which is obvious
anyway).
This is generally more descriptive, but also good for later work that
allows measuring the boot phase too.
It only really makes sense to fetch the location from either one of
these fields, depending on whether we are looking at an in-memory
(relocated) or a file PE image.
Pick up the two new sections in sd-stub and pass them as initrds into
the booted kernels, where they'll show up as
/.extra/tpm2-pcr-signature.json and /.extra/tpm2-pcr-public-key.pem in
the initrd file system.
The initrd is then supposed to pick these files up from there and save
them at a place that will survive into the host OS.
These aren't wired up yet to do anything useful. For now we just define
them.
This sections are supposed to carry a signature for expected
measurements on PCR 11 if this kernel is booted, in the JSON format
"systemd-measure sign" generates, and the public key used for the
signature.
The idea is to embedd the signature and the public key in unified
kernels and making them available to userspace, so that userspace can
easily access them and enroll (for which the public key is needed) or
unlock (for which the PCR signature is needed) LUKS2 volumes and
credentials that are bound to the currently used kernel version stream.
Why put these files in PE sections rather than just into simple files in
the initrd or into the host fs?
The signature cannot be in the initrd, since it is after all covering
the initrd, and thus the initrd as input for the calculation cannot
carry the result of the calculation. Putting the signature onto the root
fs sucks too, since we typically want to unlock the root fs with it,
hence it would be inaccessible for it's primary purpose then.
The public key could be in the initrd or in the root fs, there's no
technical restriction for that. However, I still think it's a good idea
to put it in a PE section as well, because this means the piece of code
that attaches the signature can also attach the public key easily in one
step, which is nice since it allows separating the roles of the
kernel/initrd/root fs builder, and the role of the signer, and the
former doesn't have to have knowledge about what the latter is going to
add to the image.
Note that the signature section is excluded from the TPM measurements
sd-stub does about its resource sections, since – as mentioned – it's
the expected output of the signing operation whose input are the
measurements, hence it cannot also be input to them. The public key
section is included in the measurements however.
Let's add simple helpers for passing data blobs from the stub into the
booted kernel as initrds that are generated on-the-fly.
(Note used yet, a later commit will make use of this)
This arg expects scan codes and it can be very confusing to find a key
conflict when trying to add a F3 button when there are no F3 keycodes
seemingly in use. CHAR_CARRIAGE_RETURN and SCAN_F3 use the same value,
so no changes in behavior.
When using --current switch, copy in current hash, don't just reassign
buffers forgetting about the old.
While we are at it, allocate the local copy buffer later, in
measure_pcr() as we won#t need it in the --current case.
The warning isn't that serious and mostly there to inform the user that
lld/mold cannot build efi binaries. It is also better to build test with
fatal meson warnings.
This allows allows shortcutting measurements of the specified files and
use the information from /sys/ instead.
This is not too useful on its own given that "systemd-measure status"
already exists which displays the current, relevant PCR values. The main
difference is how "complete" the information is. "status" will detect if
the measurements make any sense, and show more than PCR 11. "calculate
--current" otoh only reads PCR 11 and uses that, and that's really it.
This is mainly preparation for later work to add PCR signing to the
tool, where usually it makes most sense to sign prepared kernel images,
but for testing it's really useful to shortcut signing to the current
PCR values instead
entry.
By default an entry named "Linux Boot Manager" is created (which is the
previous behavior). With the flag the name of the entry can be
controlled, which is useful when installing systemd-boot to multiple ESP
partitions and having uniquely named entries.
Fixes#17044.
Lennart Poettering
Jan Janssen
Yu Watanabe
David Tardon
Frantisek Sumsal
Luca Boccassi
Rene Hollander