Conceptually the feature is great and should exist, but in its current
form should be worked to be generic (i.e. not specific to
Windows/Bitlocker, but appliable to any boot entry), not be global (but
be a per-entry thing), not require a BootXXXX entry to exist, and not
check for the BitLocker signature (as TPMs are not just used for
BitLocker).
Since we want to get 251 released, mark it in the documentation, in NEWS
and in code as experimental and make clear it will be reworked in a
future release. Also, make it opt-in to make it less likely people come
to rely on it without reading up on it, and understanding that it will
likely change sooner or later.
Follow-up for: #22043
See: #22390
Apparently Grub is measuring all kinds of garbage into PCR 8. Since people
apparently chainload sd-boot from grub, let's thus stay away from PCR 8,
and use PCR 12 instead for the kernel command line.
As discussed here: #22635Fixes: #22635
It's not a pointer after all, but a numeric value. As such the const
applies to the value and not the target, but we genreally don#t do that
for value parameters. Hence drop the const.
This makes a bunch of closely related changes:
1. The "entry-token" concept already introduced in kernel-install is now
made use of. i.e. specifically there's a new option --entry-token=
that can be used to explicitly select by which ID to identify boot
loader entries: the machine ID, or some OS ID (ID= or IMAGE_ID= from
/etc/os-release, or even some completely different string. The
selected string is then persisted to /etc/kernel/entry-token, so that
kernel-install can find it there.
2. The --make-machine-id-directory= switch is renamed to
--make-entry-directory= since after all it's not necessarily the
machine ID the dir is named after, but can be any other string as
selected by the entry token.
3. This drops all code to make automatic changes to /etc/machine-info.
Specifically, the KERNEL_INSTALL_MACHINE_ID= field is now more
generically implemented in /etc/kernel/entry-token described above,
hence no need to place it at two locations. And the
KERNEL_INSTALL_LAYOUT= field is not configurable by user switch or
similar anyway in bootctl, but only read from
/etc/kernel/install.conf, and hence copying it from one configuration
file to another appears unnecessary, the second copy is fully
redundant. Note that this just drops writing these fields, they'll
still be honoured when already set.
The data type off_t can be 64 on 32 bit systems if they have large
file support. Since mmap expects a size_t with 32 bits as second
argument truncation could occur. At worst these huge files could
lead to mmaps smaller than the previous check for small files.
This in turn shouldn't have a lot of impact because mmap allocates
at page size boundaries. This also made the PAGE_ALIGN call in
open_mmap unneeded. In fact it was neither in sync with other mmap
calls nor with its own munmap counterpart in error path.
If such large files are encountered, which is very unlikely in these
code paths, treat them with the same error as if they are too small.
Some firmware supports sending input events for shift and logo keys.
Previously, we would suppress these with EFI_NOT_READY unless
some other key was pressed alongside, but it is really the job of the
caller to decide how to handle these.
Note that for keys that already have a printable shift representation
the reported input event will not have the shift key bits set
(Shift+a is reported as A). Should some firmware turn out to violate the
spec here we can always remove that part.
In some cases there was a unlikely possibility that we would look
at an uninitialized key value.
Also, returning in case of unexpected input error cases should prevent
infinite looping.
On my local system I linked up the ESP and XBOOTLDR partitions, and
ended up with duplicate entries being listed. Try hard to detect that
and only enumerate entries in the ESP if it turns out that both dirs
have the same dev_t.
This should detect both bind mounted and symlinked cases and should make
our list output less confusing.
Let's improve display of boot entries and show what type they have (i.e.
boot loader spec type 1, or type 2, or auto-discovered or reported by
boot loader), and in particular mark entries the boot loader discovered
but we can't find (i.e. that likely vanished, or possibly couldn't be
found due to a misconfiguration) and that the boot loader didn't find
but we see (which are new, or possibly also the result of
misconfiguraiton).
This is supposed to be a replacement for #22161, but instead of hiding
vanished entries, highlights them, which I think is more appropriate for
a low-level tool such bootctl.
Replaces: #22161#22398
The single consumer of ticks_read() (i.e. time_usec()) checks for == 0
to detect the "not supported/invalid" case, hence actually return the
right value for that.
Note to self: should I ever become a black hat hacker, this is how I'd
hide a vulnerability. ;-)
(No, this one is not a vulnerability)
Follow-up for: 163d1ea5dd
No actual code changes, just renaming.
Rationale: the focus here should be on the fact that these are "unified"
images, whether our stub is used or not, or something else doesn't
really matter. Moreover, these are still Linux entries. Hence, emphasize
that these are *unified* images, and *Linux* images, and deemphesize
that our sd-stub is likely used.
The script was probably not used for a very long time. It is currently
passed systemd_boot.so as boot loader, which cannot work. The test
entries it creates are all pointing at non-existant efi/linux binaries,
which means they would not even show up in the menu if the created image
were actually booted. There is also nothing that actually tries to run
the image in the first place.
If we end up creating a proper systemd-boot test suite, it would be
better to start from scratch. In the meantime, mkosi already covers
the bare minimum with a simple bootup test.
The debug symbols are of very limited use in proper deployments
unlike with regular userspace. Unless someone goes through the pain
of setting up an EFI debugger (assuming their firmware even supports
this in the first place) any provided debug symbols will just be
useless.
Debugging under QEMU is possible, but even then it is non-trivial
to set up, so anyone willing to go that far can just build in
developer mode.
Meanwhile, at least x86 firmware tends to refuse binaries that contain
debug symbols. We do strip the files when converted to PE anyway, but
the elf file needs to stay around on other arches as objcopy does not
support PE as input there.
Also, the generated debug symbols seem to be not reproducible when
building with LTO. Whether this is an issue in tooling or our side
is unclear. This works around this issue.
Fixes: #22157
Remove the parameter 'only_auto' from the function
boot_entries_augment_from_loader() because each caller set it always to
true.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
When bootctl lists the boot entries, considers also the ones
returned by systemd-boot (via the efi LoaderEntries variable),
created at boot time.
Unfortunately this list may became incorrect if (e.g.) the user remove a
kernel package.
This patch changes this behaviour, so bootctl ignores some the
boot entries returned by systemd-boot.
In any case, bootctl still considers the 'auto-xxx' boot entries
listed below:
Boot entrie name Title
----------------------------- ------------------------------
auto-osx macOS boot loader
auto-windows Windows Boot Manager
auto-efi-shell EFI Shell
auto-efi-default EFI Default Loader
auto-reboot-to-firmware-setup Reboot Into Firmware Interface
The other entries that systemd-boot synthetizes (e.g. the ones loaded from
/efi/loader/entries/<uuid>) can be synthetized by bootctl too, so no
information is lost.
Signed-off-by: Goffredo Baroncelli <kreijack@inwind.it>
The device path should not contain multiple hard drive nodes in it,
so looking at them all should not be needed.
If some crazy firmware/driver were to make nested GPT drives
available like that, we should be only looking at the last partition
and its containing GPT drive anyway.
Some firmware creates partition device paths without a messaging
device path node, making the search for the xboot loader partition
fail.
Fixes: #17756
Lennart Poettering
Yu Watanabe
Jan Janssen
Alfonso Sánchez-Beato
Tobias Stoeckmann
Daan De Meyer
Goffredo Baroncelli