This also moves the message about failed image execution into
image_start() as we would otherwise show two error messages if
any of the preparatory steps failed.
The SBAT section was included in a special section in the EFI code, but
the contents weren't directly visible in any way. Let's add a "test" that
prints them for visual inspection.
If there's some external linter for this format, we could hook it up in the
future.
UEFI provides a "monotonic boot counter" which is supposed to increase on
each reboot. We can include this in our random seed hash logic, which
makes things more robust in case our changes to the ESP end up not
actually being as persistent as we assume. As long as the monotonic boot
counter increases we should be good, as each boot we'll anyway end up
with a new seed that way.
This in fact should also pave the way that we can eventually enable the
random seed logic even on SecureBoot enabled systems. Why that? With
this change the input for the random seed hash is now:
1. the old seed file contents
2. (optionally) some bits from the UEFI RNG
3. (optionally) a per system random "token" stored in an UEFI variable,
initialized at OS install
4. the UEFI monotonic counter
5. a counter integer used by the random seed logic.
We can ignore #5 entirely for security considerations, it's always going
to be a constant series of values determined by the random seed logic.
The #1 file is under control of the attacker. (Since it resides in the
unprotected ESP)
The #2 data is possibly low quality. (it's hard enough to trust the
quality of the Linux RNG, let's not go as far as trusting the UEFI one)
The #3 data should not be under control of the attacker, and should only
exist if explicitly set. Unless you have privileged access to the system
you should not be able to read or set it. (well, within limits of flash
chip security and its connectivity to the firmware)
The #4 data is provided by the firmware, and should not be under control
of the attacker. If it works correctly then it might still be guessable
(i.e. a new system might have the counter close to zero).
Thus: 1+2+5 are guessable/under control of attacker, but 3+4 should not
be. Thus, if 3 is not known to attacker and not guessable, and 4
strictly monotonically increasing then it should be enough to guarantee
that every boot will get a different seed passed in, that should not be
known or guessable by the attacker.
That all said, this patch does not enable the random seed logic on
SecureBoot. That is left for a later patch.
This is a follow-up for f470cb6d13 which in
turn is a follow-up for a068aceafb.
The latter started to honour hidden files when deciding whether a
directory is empty. The former reverted to the old behaviour to fix
issue #23220.
It introduced a bug though: when a directory contains a larger number of
hidden entries the getdents64() buffer will not suffice to read them,
since we just allocate three entries for it (which is definitely enough
if we just ignore the . + .. entries, but not ig we ignore more).
I think it's a bit confusing that dir_is_empty() can return true even if
rmdir() on the dir would return ENOTEMPTY. Hence, let's rework the
function to make it optional whether hidden files are ignored or not.
After all, I looking at the users of this function I am pretty sure in
more cases we want to honour hidden files.
Allows to quickly build systemd-boot by itself without having to
reference the full path of the build target:
$ ninja -C foo systemd-stub
ninja: Entering directory `foo'
[21/21] Generating src/boot/efi/linuxx64.efi.stub with a custom command
$ ninja -C foo systemd-boot
ninja: Entering directory `foo'
[10/10] Generating src/boot/efi/systemd-bootx64.efi with a custom command
Allows to 'meson install --tags systemd-boot --no-rebuild' to install only the EFI
binaries, skipping the rest, for a very quick build:
$ ninja src/boot/efi/linuxx64.efi.stub
[21/21] Generating src/boot/efi/linuxx64.efi.stub with a custom command
$ ninja src/boot/efi/systemd-bootx64.efi
[10/10] Generating src/boot/efi/systemd-bootx64.efi with a custom command
$ DESTDIR=/tmp/foo meson install --tags systemd-boot --no-rebuild
Installing src/boot/efi/systemd-bootx64.efi to /tmp/foo/usr/lib/systemd/boot/efi
Requires Meson 0.60 to be used, prints a warning for unknown keyword
in earlier versions, but there's no failure
https://mesonbuild.com/Installing.html#installation-tags
Let's improve the output regarding TPM2 support in "bootctl": let's show
whether we have local driver support and/or firmware support, and
colorize it.
(For now, don't show if we natively support TPM2, since the tool is
mostly bout boot time stuff, where it dosn't really matter much what we
do in userspace)
gnu-efi only knows two sizes for formatting integers: 32bit without
a length prefix and 64bit with 'l' prefix. Provide a PRI-style format
specifier for (U)INTN so that Print() can read the right amount of
bytes instead of printing garbage or worse.
No actual code changes, just splitting out of some dev_t handling
related calls from stat-util.[ch], they are quite a number already, and
deserve their own module now I think.
Also, try to settle on the name "devnum" as the name for the concept,
instead of "devno" or "dev" or "devid". "devnum" is the name exported in
udev APIs, hence probably best to stick to that. (this just renames a
few symbols to "devum", local variables are left untouched, to make the
patch not too invasive)
No actual code changes.
This allows building 32bit versions of efi binaries on x86_64 machines
and vice-versa by passing "-Defi-cflags=-m32" to meson, provided the
32bit gnu-efi and gcc-multilib are available.
It is expected that distros that want to provide both ia32 and x64
versions to use a second build dir to build the non-native version
by adding -m32 to efi-cflags and then running the sd-boot/sd-stub
ninja target directly.
We must be consistent in the two listings, so let's split out the loading code
and call it from both verb_status() and verb_list(). This effectively makes
verb_status() also call efi_loader_get_entries().
There is still some code duplicated, but that's hard to avoid. Error messages
are made identical for the same errors in various places.
Fixes#22580.
That function is nasty because it modifies global state. We should call it just
once in each call path.
Also drop 'return 1' which doesn't seem to have any use.
This normalizes naming of functions operating on BootConfig objects.
Let's always call them boot_config_xyz(), like our usual way to name
stuff.
moreover, move the BootConfig parameter to the beginning, as it's not a
return value (which we typically move to the end of the parameter list),
but simply an object, that even happens to be initialized already.
With these changes the functions are more like our usual way to call
things, and less surprises are good.
Some refactoring: split efi-loader.[ch] in two: isolate the calls that
implement out boot loader interface spec, and those which implement
access to upstream UEFI firmware features.
They are quite different in nature and behaviour, and even semantically
it makes to keep these two separate. At the very least because the
previous name "efi-loader.[ch]" suggests all was about loader-specific
APIs, but much of it is generic uefi stuff...
While we are at it, I renamed a bunch of return parameters to follow our
usual ret_xyz naming. But besides renaming no real code changes.
Same idea as 03677889f0.
No functional change intended. The type of the iterator is generally changed to
be 'const char*' instead of 'char*'. Despite the type commonly used, modifying
the string was not allowed.
I adjusted the naming of some short variables for clarity and reduced the scope
of some variable declarations in code that was being touched anyway.
bootctl so far tried to determine the layout from /etc/machine-info, but
that's obsolete, and the kernel-install script never looked there. Let's
read the setting from /etc/kernel/install.conf instead, where
kernel-install actually looks.
Support for reading the field from /etc/machine-info is retained for
compat.
This means we'll now read /etc/machine-id, /etc/machine-info and
/etc/kernel/install.conf, and read the machine ID from the former too
and the layout setting from the latter two.
With the changes in 20ec8f534f, we would sort
entries with sort-key as expected (higher versions earlier, i.e. at the top of
the menu), but entries without the sort-key as before, with higher versions
later.
When we have a bunch of boot entries grouped by machine-id (or even in the
typical case of all boot entries having the same machine id), sorting by id
should generally give good results. Entries will be grouped by installation,
and then newer entries should generally be at the top of the menu.
The code is quite different from the rest of bootspec.c, with different
deps and stuff. There's even a /***/ line to separate the two parts.
Given how large the file already is, let#s just split it into two.
No code changes, just some splitting out.
Jan Janssen
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe