$ 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
Double newlines (i.e. one empty lines) are great to structure code. But
let's avoid triple newlines (i.e. two empty lines), quadruple newlines,
quintuple newlines, …, that's just spurious whitespace.
It's an easy way to drop 121 lines of code, and keeps the coding style
of our sources a bit tigther.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
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.
This patch improves the automatic console mode switching by avoiding
changing the mode if it can verify that the text is readable in the
default mode. The implementation avoids changing mode if we're using a
low resolution device (fixed to be smaller than 1920x1080) because we
assume the text is readable, so the initial mode should be a good one.
Also, the mode is not changed when in high resolution mode if the text
viewport area is larger than 10% of the screen. The conclusion is that
only if the text viewport is calculated to occupy less than 10% of the
screen area it is assumed to be hard to read and a new mode is selected.
With this patch the auto mode will typically avoid changing mode
hopefully in most of the cases, only changing it if completely
necessary.
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.
currently if a stub image is directly booted, bootctl reports:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─/EFI/Secure/secure-boot-4.14.8+.efi
```
Let's add a StubInfo which will be displayed by bootctl too (in a later
patch).
when an image with the stub is booted directly from UEFI, bootctl status
shows this:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─n/a
```
After this change, the stub reports the image itself:
```
Current Loader:
Product: n/a
ESP: /dev/disk/by-partuuid/b0a0807d-0592-40e9-adac-3bb724e9e305
File: └─/EFI/Secure/secure-boot-4.14.8+.efi
```
Our CODING_STYLE suggests not comparing with NULL, but relying on C's
downgrade-to-bool feature for that. Fix up some code to match these
guidelines. (This is not comprehensive, the coccinelle output for this
is unfortunately kinda borked)
Setting the secure_boot flag, avoids getting the printout
"EFI stub: UEFI Secure Boot is enabled." when booting
a Linux kernel with linuxx64.efi.stub and EFI SecureBoot enabled.
This is mainly a cosmetic fixup, as the "quiet" kernel parameter does
not silence pr_efi printouts in the linux kernel (this only works using
the efi stub from the linux source tree)
The comment above makes the intent of the code pretty clear:
"use security2_protocol == NULL as indicator".
So revert the condition in the check and fix the logic in the comment while
at it.
The question is how this could have ever worked: if BS->LocateProtocol
(which is supposedly optional) ever failed, we'd crash here. Strange.
Found by coverity.
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
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.
Using conf.set() with a boolean argument does the right thing:
either #ifdef or #undef. This means that conf.set can be used unconditionally.
Previously I used '1' as the placeholder value, and that needs to be changed to
'true' for consistency (under meson 1 cannot be used in boolean context). All
checks need to be adjusted.
This small fixup removes a compiler warning when passing tcg (a const
arg type) to the uefi call wapper, which does not define it as const.
All other source files in sd-boot do this cast except measure.c, so
let's fix that.
This fixes ldsdir detection under Debian.
v2:
- define gnu_efi_arch for the arch efi include directory name
In the autotools naming convention, efi_arch and this directory always had
the same name. But meson.cpu_family() uses a slightly different convention,
so those two don't always match.
Shell scripts should be executable so that meson reports their
invocation succinctly (does not print 'sh' '-e').
Python scripts should not be executable so that meson does the
detection of the right python binary itself.
Add -u everywhere to catch potential errors.
