IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Not aligning these can create gaps in the section table. Some
firmware does not handle this nicely resulting in secure boot
signature fails.
Using objcopy ensures that any new sections in the future will be
properly aligned.
Fixes: #21956
(cherry picked from commit 75747c8a39)
The data seems to be properly aligned in real BCD stores, so it
should be fine to just reject bad ones.
Fixes: #21917
(cherry picked from commit 1cadb35fd6)
LibLocateProtocol will return the protocol for the first device that
supports it. But it may not actually come from the ConIn device that
we want to use here.
This should be the root cause of what was previously considered just
broken firmware. If you ask the wrong device to return some key, of
course it will never provide one.
This changes the way we handle input yet again in light of this new
knowledge and because using the correct TextInputEx with fallback to
ConIn can actually create double input in some cases.
Since we are now confident that we get the right TextInputEx, we can
use that exclusively, only falling back to ConIn if the console input
device does not support the better interface (the spec is pretty clear
that it must support it, though).
Because some firmware is broken, we still need to provide a fallback
to the previously used TextInputEx thats overrides ConIn/ConInEx if
it is functional.
Now that kernel-install creates the machine-id directory, we don't need to do
this is 'bootctl install', and in fact it's better not to do this since it
might never be necessary. So let's change the default behaviour to 'no'.
I kept support for 'auto' to maintain backwards compatibility, even though the
default was changed. Previous behaviour can be requested by specifying
--make-machine-id-directory=auto.
This is a natural extension of d6bce6e224: if we are installing sd-boot, we
want to use the sd-boot layout, so let's write the appropriate
KERNEL_INSTALL_LAYOUT setting. Effectively, if we do 'booctl install',
kernel-install will not autodetect the layout anymore.
And 357376d0bb added support for KERNEL_INSTALL_MACHINE_ID. We need to support
it here too. We both read it, so that we create the right directories, and also
write it if it wasn't written yet and we created some directories using it, so
that kernel-install that is executed later knows the machine-id that matches
the directories we crated.
The code is changed in some places to fail if we can't figure out the current
status. When installing the boot loader it's probably better not to guess.
This replaces the memmem-based approach of finding a suitable title
for the windows boot manager with one that actually parses the BCD
store. It's probably faster but more importantly, it's more correct.
The memmem approach may detect stale title strings that are still
in the file but unused due to the way registry hives are updated.
This approach also allows us to detect if the BCD store is multi-boot
so that we can fall back on the generic one instead.
The gnu-efi headers emit some warnings in clang when not compiled with
-ffreestanding. This is normally not an issue for has_header_symbol()
unless meson is run with CFLAGS="-Werror". Note that this differs
from the --werror option, which does not get passed to clang.
Work around this by adding some compile args to the has_header_symbol()
invocation.
Some types of credentials that a user would want to pass
into the initrd do not depend on the specific kernel/initrd
version. For instance, this can include SSH keys, rootfs
encryption keys, dm-integrity keys, and so on. This
introduces a directory where such credentials can be placed
so that any kernel image will load them
if /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed exists
install that instead of /usr/lib/systemd/boot/efi/systemd-bootx64.efi
the idea is that SecureBoot tooling can create the efi.signed file
whenever /usr/lib/systemd/boot/efi/systemd-bootx64.efi from the package
is updated.
Previously, mangle_filename would write the null terminator, but
then wouldn't increment the pointer. Thus, the pad4 call that comes
immediately after mangle_filename would trample over the null
terminator that mangle_filename wrote. Since the padding is all
0s, this happened to work for the filenames it was tested for
However, in some cases, this would cause the pointer to be a different
position than predicted. Basically, the predicted size would be one
byte bigger than the actual size (the missing null terminator). Usually,
this disappeared into the alignment padding at the end of the buffer,
but if the buffer was already unexpectedly aligned (b/c it was a byte
shorter than expected), this would cause assertion failures.
Also, the c_namesize field in the cpio header was incorrect. It
didn't include the null terminator, as required by the spec.
For LTO to work, the linker has to be called with some magic sauce arguments.
And the easiest way to get those is to just let the compiler to the job for us.
Any recent shim will refuse starting an image that does not have an sbat section
and will do so with a generic "Security Violation" message. And it is very easy
to forget passing -Dsbat-distro=auto to meson when creating a fresh build dir.
Adding sbat info when shim is not used or secure boot is disabled does not hurt
anyone, so default to auto. This still ensures to not add auto-detected info in
case we are cross building.
