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.
Adding Microsoft keys by default is recommended because firmware drivers
might be signed by it.
This also changes the file ending from .esl to .auth as that is used by
sign-efi-sig-list manpage and other sources.
***DANGER*** NOTE ***DANGER***
This feature might result in your device becoming soft-brick as outlined
below, please use this feature carefully.
***DANGER*** NOTE ***DANGER***
If secure-boot-enrollment is set to no, then no action whatsoever is performed,
no matter the files on the ESP.
If secure boot keys are found under $ESP/loader/keys and secure-boot-enrollment
is set to either manual or force then sd-boot will generate enrollment entries
named after the directories they are in. The entries are shown at the very bottom
of the list and can be selected by the user from the menu. If the user selects it,
the user is shown a screen allowing for cancellation before a timeout. The enrollment
proceeds if the action is not cancelled after the timeout.
Additionally, if the secure-boot-enroll option is set to 'force' then the keys
located in the directory named 'auto' are going to be enrolled automatically. The user
is still going to be shown a screen allowing them to cancel the action if they want to,
however the enrollment will proceed automatically after a timeout without
user cancellation.
After keys are enrolled, the system reboots with secure boot enabled therefore, it is
***critical*** to ensure that everything needed for the system to boot is signed
properly (sd-boot itself, kernel, initramfs, PCI option ROMs).
This feature currently only allows loading the most simple set of variables: PK, KEK
and db.
The files need to be prepared with cert-to-efi-sig-list and then signed with
sign-efi-sig-list.
Here is a short example to generate your own keys and the right files for
auto-enrollement.
`
keys="PK KEK DB"
uuid="{$(systemd-id128 new -u)}"
for key in ${keys}; do
openssl req -new -x509 -subj "/CN=${key}/ -keyout "${key}.key" -out "${key}.crt"
openssl x509 -outform DER -in "${key}.crt" -out "${key}.cer"
cert-to-efi-sig-list -g "${uuid}" "${key}.crt" "${key}.esl.nosign"
done
sign-efi-sig-list -c PK.crt -k PK.key PK PK.esl.nosign PK.esl
sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.esl.nosign KEK.esl
sign-efi-sig-list -c KEK.crt -k KEK.key db db.esl.nosign db.esl
`
Once these keys are enrolled, all the files needed for boot ***NEED*** to be signed in
order to run. You can sign the binaries with the sbsign tool, for example:
`
sbsign --key db.key --cert db.crt bzImage --output $ESP/bzImage
`
Example:
Assuming the system has been put in Setup Mode:
`
$ESP/loader/keys/auto/db.esl
$ESP/loader/keys/auto/KEK.esl
$ESP/loader/keys/auto/PK.esl
$ESP/loader/keys/Linux Only/db.esl
$ESP/loader/keys/Linux Only/KEK.esl
$ESP/loader/keys/Linux Only/PK.esl
$ESP/loader/keys/Linux and Windows/db.esl
$ESP/loader/keys/Linux and Windows/KEK.esl
$ESP/loader/keys/Linux and Windows/PK.esl
`
If auto-enroll is set, then the db, KEK and then PK are enrolled from the 'auto'
directory.
If not, three new boot entries are available to the user in order to enroll either the
'Linux Only', 'Linux And Windows' or 'auto' set of keys.
For now, this simply outputs the PCR hash values expected for a kernel
image, if it's measured like sd-stub would do it.
(Later on, we can extend the tool, to optionally sign these
pre-calculated measurements, in order to implement signed PCR policies
for disk encryption.)
Jan Janssen
Lennart Poettering
Yu Watanabe
David Tardon
Frantisek Sumsal
Luca Boccassi
Rene Hollander
Vincent Dagonneau