The casts in this and the next few commits are curently necessary
because CHAR8 is defined as uint8_t in gnu-efi, while char is signed.
Once we switch from gnu-efi typedefs to stdint types, the casts
will be dropped.
We currently have a convoluted and complex selection of which random
numbers to use. We can simplify this down to two functions that cover
all of our use cases:
1) Randomness for crypto: this one needs to wait until the RNG is
initialized. So it uses getrandom(0). If that's not available, it
polls on /dev/random, and then reads from /dev/urandom. This function
returns whether or not it was successful, as before.
2) Randomness for other things: this one uses getrandom(GRND_INSECURE).
If it's not available it uses getrandom(GRND_NONBLOCK). And if that
would block, then it falls back to /dev/urandom. And if /dev/urandom
isn't available, it uses the fallback code. It never fails and
doesn't return a value.
These two cases match all the uses of randomness inside of systemd.
I would prefer to make both of these return void, and get rid of the
fallback code, and simply assert in the incredibly unlikely case that
/dev/urandom doesn't exist. But Luca disagrees, so this commit attempts
to instead keep case (1) returning a return value, which all the callers
already check, and fix the fallback code in (2) to be less bad than
before.
For the less bad fallback code for (2), we now use auxval and some
timestamps, together with various counters representing the invocation,
hash it all together and provide the output. Provided that AT_RANDOM is
secure, this construction is probably okay too, though notably it
doesn't have any forward secrecy. Fortunately, it's only used by
random_bytes() and not by crypto_random_bytes().
The kernel provides a ".compat" PE section that contains a list of
compat entry points with their respective arches. This entry point
does all the heavy lifting to support running 64bit kernels when
the UEFI firmware is 32bit.
Note that the EFI handover protocol code in linux_x86.c does not
need any adjustments as it already correctly calls the 32bit handover
code.
Fixes: #17056
This is in preparation for LINUX_INITRD_MEDIA support in boot.c. One
downside is that adding or changing the used initrds by command line
editing is not possible anymore.
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.
Jan Janssen
Jason A. Donenfeld
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Lennart Poettering
Yu Watanabe