$ 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.
While it doesn't really make much sense to set "auto-reboot-to-firmware"
as oneshot boot item, let's still support it properly, by also
dispatching such a menu item if selected.
Let's stick to one nomenclature. In userspace we usually call this
"reboot to firmware setup", hence use the same name in sd-boot too.
This name was previously only relevant internally, but since the
addition of the LoaderEntries EFI var is exposed to userspace, hence
let's get this right with the first release adding this.
We keep adding new features, let's advertise to the host OS what these
are in a new variable LoaderFeatures.
It works a bit like OsIndicationsSupported, but is about Loader
features.
This is primarily useful for debugging, but can be useful for other
purposes too. For example userspace could check whether "auto-windows"
is included in the list, before triggering a boot-into-windows
operation.
The field derives from a file name only in very specific cases, for
many cases it's a fixed string (for example, all "auto-" items are like
this). Also, even when it derives from a file name, it is processed a
bit, as suffixes are removed and the string is converted to lower case.
hence, let's name this field "id" instead, because that's what it is
used for: as general identification token.
$ git grep -e 'This program is free software' -l |grep -v LICENSE | \
xargs perl -i -0pe 's/ \* This program.*?for more details.\s*\*\n( \* You should have.*licenses.>.\n)?//gms'
For some reason they were missed previously. All those files seem to
have proper SDPX tags.
UINTN is the integer type equalling the native ptr size. Let's fix the
casting warnings described in #7788 by casting the the pointers and
values to this type first. That way we cast integers to the right size
first before turning them into pointers, and pointers are first
covnerted to integers of the right size before converting them into
integers.
Not tested, since I lack i386 EFI systems, but I think this is simple
enough to be correct event without testing.
Fixes: #7788
We don't need to check if we are adding ourselves to the list
if we know that it's the windows or EFI shell loaders.
If we are adding the EFI default loader, additionally try to
see if we can find the systemd-boot magic string and skip
this entry if we do.
The new boot option allows changing the display console mode to some new
display resolution.
Usage: in systemd-boot configuration file loader/loader.conf add one of:
console-mode <number>
console-mode auto
console-mode max
console-mode keep
Where number can be:
1) 0: UEFI standard 80x25 mode
2) 1: 80x50 mode, if supported by device
3) 2 or greater: some non-standard device mode, if supported
When using the auto mode, systemd-boot will try to find a reasonable
mode automatically using some heuristic. Current implementation tries to
switch console mode to mode 2 if it exists, mode 1 if it exists, else
mode 0. Mode 2 is the first non standard mode provided by the firmware
developer and it's assumed to be a reasonable mode.
The max mode adds support for switching to the highest numbered console
mode, whatever mode that would be in the system. The maximum mode being
the last one implemented by the firmware provider should be a reasonable
mode.
The keep mode is the default and is only included for completeness. With
this parameter, the user explicitly states and can be assured that
systemd-boot will not change console mode.
Note: patch includes a workaround for mode 1, that may not exist in
EDK2 OVFM and results in a buggy text mode when requested.
Hiding automatic entries allows for giving custom entry names like
"Windows 10" instead of "Windows Boot Manager" by creating an appropriate
loader file in the loader/entries folder.
Note that it is already doable by renaming bootmgfw.efi (or the other auto-detected
boot loaders) and then using the renamed file for a custom entry. But windows will
automatically recreate the boot loader on updates, including the default EFI
bootloader entry if that one is missing.
Make hiding EFI reboot a separate option because there is no simple way to create
it with a custom loader entry and people may still want that around while still
hiding the other auto entries.
Also, turn no_editor into a positive boolean name while we're touching this code.
file_read() wants to return both a EFI_STATUS (INTN) and a file
length (UINTN). This seems rather fishy for either large files or
when returning errors (which are defined as positive numbers).
Let's just be more clear and return EFI_STATUS and let the file
length be a pointer.
There's a slight change in implementation: we first try to append the
version, then look for any non-unique pairs again. Before, we would only
mark as possibly unique those entries we changed. But if there are two
entries that e.g. have the same title and version, but only one has the
machine-id specified, we would treat one of them as still non-unique after
appending the machine-id to the other one. So the new algorithm is simpler
but more robust (not that it matters).
The advantage is that is the name is mispellt, cpp will warn us.
$ git grep -Ee "conf.set\('(HAVE|ENABLE)_" -l|xargs sed -r -i "s/conf.set\('(HAVE|ENABLE)_/conf.set10('\1_/"
$ git grep -Ee '#ifn?def (HAVE|ENABLE)' -l|xargs sed -r -i 's/#ifdef (HAVE|ENABLE)/#if \1/; s/#ifndef (HAVE|ENABLE)/#if ! \1/;'
$ git grep -Ee 'if.*defined\(HAVE' -l|xargs sed -i -r 's/defined\((HAVE_[A-Z0-9_]*)\)/\1/g'
$ git grep -Ee 'if.*defined\(ENABLE' -l|xargs sed -i -r 's/defined\((ENABLE_[A-Z0-9_]*)\)/\1/g'
+ manual changes to meson.build
squash! build-sys: use #if Y instead of #ifdef Y everywhere
v2:
- fix incorrect setting of HAVE_LIBIDN2
Display the error for a small amount of time, but don't fail hard.
In case of a faulty BIOS, a TPM error should not prevent the boot.
If something cares about the PCM measurement, it will be noticed
anyway later on.
Especially important now, that TPM measurement is the default now on
some distribution builds.
https://bugzilla.redhat.com/show_bug.cgi?id=1411156
This makes it more like other configure defines.
Also, it fixes meson status output which was looking for HAVE_ and ENABLE_
prefixes only (the define under meson was OK, just the summary message was
wrong.)
In a Secure Boot scenario the stub loader will have been validated
before execution. A malicious drive could then change the data returned
in future reads, resulting in the loader obtaining incorrect section
offsets and (for instance) allowing the command line to be modified.
Pull that information out of the in-RAM representation of the loader
instead in order to avoid this.
Fixes: #6230
(Lennart did some minor coding style fixes, and renamed pefile.c → pe.c,
as suggested by Kay, given that the file now contains a function whose
name doesn't match the filename as prefix anymore.)
Adds support for booting in a SecureBoot environment with shim as a
preloader. Install an appropriate UEFI security policy to check PE
signature of a chained kernel or UEFI application (using LoadImage())
against the MOK database maintained by shim, using shim's installed
BootServices.
Implementation details for installing the security policy are based on
code from the LinuxFoundation's SecureBoot PreLoader, part of efitools
licensed under LGPL 2.1
Current signed (by Microsoft) versions of shim (Versions 0.8 & 0.9)
so not install a security policy by themselves, future Versions of
shim might (a compile time switch exists in rectent git versions),
so in the future this PR might become unnecessary.
We defined both $(VERSION) and $(PACKAGE_VERSION) with the same contents.
$(PACKAGE_VERSION) is slightly more descriptive, so settle on that, and
drop the other define.
The UEFI BIOS already hashes the contents of the loaded image, so the
initrd and the command line of the binary are recorded.
Because manually added LoadOptions are not taken into account, these
should be recorded also.
This patch logs and extends a TPM PCR register with the LoadOptions.
This feature can be enabled with configure --enable-tpm
The PCR register index can be specified with
configure --with-tpm-pcrindex=<NUM>
