We had all kinds of indentation: 2 sp, 3 sp, 4 sp, 8 sp, and mixed.
4 sp was the most common, in particular the majority of scripts under test/
used that. Let's standarize on 4 sp, because many commandlines are long and
there's a lot of nesting, and with 8sp indentation less stuff fits. 4 sp
also seems to be the default indentation, so this will make it less likely
that people will mess up if they don't load the editor config. (I think people
often use vi, and vi has no support to load project-wide configuration
automatically. We distribute a .vimrc file, but it is not loaded by default,
and even the instructions in it seem to discourage its use for security
reasons.)
Also remove the few vim config lines that were left. We should either have them
on all files, or none.
Also remove some strange stuff like '#!/bin/env bash', yikes.
Coverity CID#1399116:
> Potentially overflowing expression
> gpt_header_buffer.gpt_header.SizeOfPartitionEntry * gpt_header_buffer.gpt_header.NumberOfPartitionEntries
> with type unsigned int (32 bits, unsigned) is evaluated using 32-bit
> arithmetic, and then used in a context that expects an expression of type
> UINTN (64 bits, unsigned).
Let's import the ALIGN_TO macro to sd-boot and use it to avoid the issue.
We document and all our code assumes that LoaderDevicePartUUID is
initialized to the ESP's UUID. Let's hence not override the variable if
it is already set, in order to not confuse userspace if the kernel's EFI
image is run from a different partition than the ESP.
This matches behaviour for all other variables set by the EFI stub, in
particular the closely related LoaderImageIdentifier variable.
Our own variables are in the the "loader" GUID namespace, but our code
so far checked the "global" GUID namespace (i.e. EFI's own), before
setting the variables. Correct that, so that we always check the right
namespace for existing variables before we write them.
The specification always said so, let's actually implement this.
Unfortunately UEFI's own APIs don't allow us to search for partition
type GUID, hence we have to implement a minimal GPT parser ourselves.
In a follow-up commit we'd like to invoke config_entry_add_from_file()
on partitions that are not the ESP, let's prepare fpr that and allow
loaded_image_path to be passed as NULL.
This makes the code a bit simpler (after all the call is not interested
in the loaded image, just where it is found), and more like
config_load_entries() which takes the same arguments.
This also makes things easier for us later on, when we add support for
discovering images in $XBOOTLDR partitions.
The current implementation copied the *complete* header to boot_params,
thus making the kernel ignore many of the fields.
As mentioned in the code comment for the sentinel variable in
bootparam.h a bootloader should only copy the setup_header, set some
fields in boot_params and zero out anything else.
This change makes systemd-boot (mostly) compliant with the Linux Boot
Protocol and the EFI Handover Protocol described in bootparam.h and
Documentation/boot.txt to fix various issues:
- Secure boot not being detected corretly by Linux (#11717)
- tboot error message / warning on boot (#11717)
- Strange purple text color when booting in qemu with OVMF
- Hopefully even more ...
This reverts commit b4f9f2a62f.
Revert this because a) the quiet bug is fixed in linux and b)
Documentation/boot.txt says "All other fields should be zero."
The GNU gold linker uses the section name `.rela.dyn` instead of
`.rela` for containing the relocation information. If this section
is not copied systemd-boot can crash.
Efitools started using wildcard section copies in their commit
b98d381b, and these wildcard sections are the only difference between
systemd-boot's section copy list and theirs. This patch add the
wildcard section `.rel*` to our objcopy, as it should include all
other wildcards assuming a recent GNU objcopy. Redundant arguments
for sections that would be matched by this wildcard are removed.
This patch has been tested on EDK II UEFI v2.70 Firmware on QEMU, and
Lenovo 0.5120 UEFI 2.40 Firmware on bare metal.
Fixes: #11541
https://hamberg.no/erlend/posts/2013-02-18-static-array-indices.html
This only works with clang, unfortunately gcc doesn't seem to implement the check
(tested with gcc-8.2.1-5.fc29.x86_64).
Simulated error:
[2/3] Compiling C object 'systemd-nspawn@exe/src_nspawn_nspawn.c.o'.
../src/nspawn/nspawn.c:3179:45: warning: array argument is too small; contains 15 elements, callee requires at least 16 [-Warray-bounds]
candidate = (uid_t) siphash24(arg_machine, strlen(arg_machine), hash_key);
^ ~~~~~~~~
../src/basic/siphash24.h:24:64: note: callee declares array parameter as static here
uint64_t siphash24(const void *in, size_t inlen, const uint8_t k[static 16]);
^~~~~~~~~~~~
$ 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.
We follow no general rule, but in most cases we do not place a space
outside of macro.h. Hence let's stick to that, and adapt macro.h too,
and follow the rule systematically that there shall not be a space
between __attribute__ and ((...
Yes, this does not matter at all, and is purely OCD cosmetics. But then
again, the uses of __attribute__ are very local only, hence the changes
cleaning this up are small and are unlikely to have to be repeated too
often...
As suggest here:
https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html#Attribute-Syntax
"You may optionally specify attribute names with ‘__’ preceding and
following the name. This allows you to use them in header files without
being concerned about a possible macro of the same name. For example,
you may use the attribute name __noreturn__ instead of noreturn. "
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.
Since both LLVM and gcc supported this for a long time, we are not
adding a fallback compat kludge. And even if there's some relevant
compiler that doesn't know this concept, it'll fail with a compiler
error, and we'll fix it then.
As suggested by @keszybz:
https://github.com/systemd/systemd/pull/10174#discussion_r226266540
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.
