This PR reverts #4302 and part of #7568, as the call to GetEventLog
isn't necessary to get the logs from the OS runtime.
This has already been reverted in shim, see:
https://github.com/rhboot/shim/commit/fd7c3bd920ba39082cb7c619afb7203d150a4cd3
The reasoning for the change that added this is wrong, explained below:
> According to TCG EFI Protocol Specification for TPM 2.0 family,
> all events generated after the invocation of EFI_TCG2_GET_EVENT_LOG
> shall be stored in an instance of an EFI_CONFIGURATION_TABLE aka
> EFI TCG 2.0 final events table.
This is correct and a valid reading of the TCG spec.
> Hence, it is necessary to trigger the internal switch through calling
> get_event_log() in order to allow to retrieve the logs from OS runtime.
However, this reasoning is incorrect. The "EFI TCG 2.0 final events
table" exists to allow the OS Runtime to get TCG events created during
or after the call to ExitBootServices. If systemd-boot didn't call
trigger_tcg2_final_events_table(), the call to HashLogExtendEvent will
write the event to the normal events table (i.e. the same place the
PCR 0 - 7 related events are written). Then the OS can obtain these
systemd-boot events in the same way it obtains normal events, via a
call to GetEventLog().
Tested on amd64 w/ TPM2 using the newest Linux kernel patches that
get the TPM2 formatted log:
https://www.lkml.org/lkml/2019/5/20/1590
I confirmed that this change still lets the OS runtime obtain the log
entries created by systemd-boot.
Signed-off-by: Joe Richey <joerichey@google.com>
The reasoning is the same as in previous cases. We get an error like
"Failed to update EFI variable: Operation not permitted" anyway, so
the check is not very useful.
If we lack permissions, we will fail anyway. But by not doing the artifial
check, we get more information. For example, on my machine, I see
$ build/systemd-bless-boot good
Not booted with boot counting in effect.
while "Need to be root" is actually untrue, because being root doesn't change
the outcome in any way.
Letting the operation fail on the actual error makes it easier to do test runs:
we *know* the command will fail, but we want to see what the first step would
be.
Not doing the articial check makes it also easier to do create alternative
security arrangements, for example where the directories are mounted with
special ownership mode and an otherwise unprivileged user can perform certain
operations.
We had all kinds of indentation: 2 sp, 3 sp, 4 sp, 8 sp, and mixed.
4 sp was the most common, in particular the majority of scripts under test/
used that. Let's standarize on 4 sp, because many commandlines are long and
there's a lot of nesting, and with 8sp indentation less stuff fits. 4 sp
also seems to be the default indentation, so this will make it less likely
that people will mess up if they don't load the editor config. (I think people
often use vi, and vi has no support to load project-wide configuration
automatically. We distribute a .vimrc file, but it is not loaded by default,
and even the instructions in it seem to discourage its use for security
reasons.)
Also remove the few vim config lines that were left. We should either have them
on all files, or none.
Also remove some strange stuff like '#!/bin/env bash', yikes.
Example output:
title: Fedora 30 (Workstation Edition) (5.0.5-300.fc30.x86_64)
id: 08a5690a2eed47cf92ac0a5d2e3cf6b0-5.0.5-bad-300.fc30.x86_64
source: /boot/efi/loader/entries/08a5690a2eed47cf92ac0a5d2e3cf6b0-5.0.5-bad-300.fc30.x86_64.conf
version: 5.0.5-300.fc30.x86_64
machine-id: 08a5690a2eed47cf92ac0a5d2e3cf6b0
linux: /08a5690a2eed47cf92ac0a/5.0.5-300.fc30.x86_64/linux (No such file or directory)
initrd: /08a5690a2eed47cf92ac0a/5.0.5-300.fc30.x86_64/initrd (No such file or directory)
/08a5690a2eed47cf92ac0a/5.0.5-300.fc30.x86_64/initrd2 (No such file or directory)
options: ...
I think this is more useful (because it's easy to stick the path into an editor command
when one wants to change the options or inspect the files), and more self-explanatory.
Example output:
title: Fedora 30 (Workstation Edition) (4.20.16-200.fc29.x86_64)
id: 08a5690a2eed47cf92ac0a5d2e3cf6b0-4.20.16-200.fc29.x86_64
source: /boot/efi/loader/entries/08a5690a2eed47cf92ac0a5d2e3cf6b0-4.20.16-200.fc29.x86_64.conf
version: 4.20.16-200.fc29.x86_64
...
title: Fedora 30 (Workstation Edition)
id: fedora-30
source: /boot/efi/EFI/Linux/linux-5.0.5-300.fc30.x86_64-08a5690a2eed47cf92ac0a5d2e3cf6b0.efi
linux: EFI/Linux/linux-5.0.5-300.fc30.x86_64-08a5690a2eed47cf92ac0a5d2e3cf6b0.efi
...
title: Reboot Into Firmware Interface
id: auto-reboot-to-firmware-setup
source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
Coverity CID#1399116:
> Potentially overflowing expression
> gpt_header_buffer.gpt_header.SizeOfPartitionEntry * gpt_header_buffer.gpt_header.NumberOfPartitionEntries
> with type unsigned int (32 bits, unsigned) is evaluated using 32-bit
> arithmetic, and then used in a context that expects an expression of type
> UINTN (64 bits, unsigned).
Let's import the ALIGN_TO macro to sd-boot and use it to avoid the issue.
Previously, bootctl would show boot loader entries discovered by the
boot loader which couldn't found locally separately in the output.
Let's move this code into bootspec.c, and beef it up a bit. This way we
can use it later on for logind, and correctly show automatically
discovered windows/macos entries too.
Previously, when we'd copy an individual file we'd synthesize a
user.crtime_usec xattr with the source's creation time if we can
determine it. As the creation/birth time was until recently not
queriable form userspace this effectively just propagated the same xattr
on the source to the same xattr on the destination. However, current
kernels now allow to query the birthtime using statx() and we do make
use of that now. Which means that suddenly we started synthesizing these
xattrs much more regularly.
Doing this actually does make sense, but only in very few cases:
not for the typical regular files we copy, but certainly when dealing
with disk images. Hence, let's keep this kind of propagation, but let's
make it a flag and default to off. Then turn it on whenever we deal with
disk images, and leave it off otherwise.
This is particularly relevant as overlayfs combining a real fs, and a
tmpfs on top will result in EOPNOTSUPP when it is attempted to open a
file with xattrs for writing, as tmpfs does not support xattrs, and
hence the copy-up cannot work. Hence, let's avoid synthesizing this
needlessly, to increase compat with overlayfs.
We document and all our code assumes that LoaderDevicePartUUID is
initialized to the ESP's UUID. Let's hence not override the variable if
it is already set, in order to not confuse userspace if the kernel's EFI
image is run from a different partition than the ESP.
This matches behaviour for all other variables set by the EFI stub, in
particular the closely related LoaderImageIdentifier variable.
Our own variables are in the the "loader" GUID namespace, but our code
so far checked the "global" GUID namespace (i.e. EFI's own), before
setting the variables. Correct that, so that we always check the right
namespace for existing variables before we write them.
The specification always said so, let's actually implement this.
Unfortunately UEFI's own APIs don't allow us to search for partition
type GUID, hence we have to implement a minimal GPT parser ourselves.
In a follow-up commit we'd like to invoke config_entry_add_from_file()
on partitions that are not the ESP, let's prepare fpr that and allow
loaded_image_path to be passed as NULL.
This makes the code a bit simpler (after all the call is not interested
in the loaded image, just where it is found), and more like
config_load_entries() which takes the same arguments.
This also makes things easier for us later on, when we add support for
discovering images in $XBOOTLDR partitions.
The current implementation copied the *complete* header to boot_params,
thus making the kernel ignore many of the fields.
As mentioned in the code comment for the sentinel variable in
bootparam.h a bootloader should only copy the setup_header, set some
fields in boot_params and zero out anything else.
This change makes systemd-boot (mostly) compliant with the Linux Boot
Protocol and the EFI Handover Protocol described in bootparam.h and
Documentation/boot.txt to fix various issues:
- Secure boot not being detected corretly by Linux (#11717)
- tboot error message / warning on boot (#11717)
- Strange purple text color when booting in qemu with OVMF
- Hopefully even more ...
This reverts commit b4f9f2a62f.
Revert this because a) the quiet bug is fixed in linux and b)
Documentation/boot.txt says "All other fields should be zero."
The GNU gold linker uses the section name `.rela.dyn` instead of
`.rela` for containing the relocation information. If this section
is not copied systemd-boot can crash.
Efitools started using wildcard section copies in their commit
b98d381b, and these wildcard sections are the only difference between
systemd-boot's section copy list and theirs. This patch add the
wildcard section `.rel*` to our objcopy, as it should include all
other wildcards assuming a recent GNU objcopy. Redundant arguments
for sections that would be matched by this wildcard are removed.
This patch has been tested on EDK II UEFI v2.70 Firmware on QEMU, and
Lenovo 0.5120 UEFI 2.40 Firmware on bare metal.
Fixes: #11541
https://hamberg.no/erlend/posts/2013-02-18-static-array-indices.html
This only works with clang, unfortunately gcc doesn't seem to implement the check
(tested with gcc-8.2.1-5.fc29.x86_64).
Simulated error:
[2/3] Compiling C object 'systemd-nspawn@exe/src_nspawn_nspawn.c.o'.
../src/nspawn/nspawn.c:3179:45: warning: array argument is too small; contains 15 elements, callee requires at least 16 [-Warray-bounds]
candidate = (uid_t) siphash24(arg_machine, strlen(arg_machine), hash_key);
^ ~~~~~~~~
../src/basic/siphash24.h:24:64: note: callee declares array parameter as static here
uint64_t siphash24(const void *in, size_t inlen, const uint8_t k[static 16]);
^~~~~~~~~~~~
$ build/systemctl --version
systemd 239-3555-g6178cbb5b5
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
$ git tag v240 -m 'v240'
$ ninja -C build
ninja: Entering directory `build'
[76/76] Linking target fuzz-unit-file.
$ build/systemctl --version
systemd 240
+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN +PCRE2 default-hierarchy=hybrid
This is very useful during development, because a precise version string is
embedded in the build product and displayed during boot, so we don't have to
guess answers for questions like "did I just boot the latest version or the one
from before?".
This change creates an overhead for "noop" builds. On my laptop, 'ninja -C
build' that does nothing goes from 0.1 to 0.5 s. It would be nice to avoid
this, but I think that <1 s is still acceptable.
Fixes#7183.
PACKAGE_VERSION is renamed to GIT_VERSION, to make it obvious that this is the
more dynamically changing version string.
Why save to a file? It would be easy to generate the version tag using
run_command(), but we want to go through a file so that stuff gets rebuilt when
this file changes. If we just defined an variable in meson, ninja wouldn't know
it needs to rebuild things.
