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
Creating a pipe with O_NONBLOCK causes both the read and the write end to
be marked as non-blocking.
The "write" end is passed to the kernel autofs module, and it does not
expect a non-blocking pipe. If it gets -EAGAIN when trying to write
(which is unlikely, but not completely impossible), it will close the
write end of the pipe, which leads to unexpected errors.
So change the code to only set O_NONBLOCK on the "read" end of the
pipe. This is the only end that systemd interacts with, so the only end
it should be configuring.
When there is bad link in the network the carrier goes up/down.
This makes networkd stops all the clients and drop config.
But if the remote router/dhcpserver running a prevention
of DHCP Starvation attack or DHCP Flood attack it does not allow
networkd to take a DHCP lease resulting failure in configuration.
This patch allows to keep the client running and keep the conf
also for this scenario.
Closes#9111
Most of the accesses *were* aligned. The only one that definetely wasn't was to
drive_path->part_start and drive_path->part_size, because those both expect
8 byte alignment, and are at offsets 4 and 12 in the packed structure.
Because of the way that device_path structure is defined and used, we expect
that device_path.length is always two-byte aligned.
This adds asserts in various places to ensure the proper alignment, and uses
memcpy in other places where the alignment might be off.
When looking for the terminating double-NUL, don't just read the memory
until the terminator is found, but use the information we got about the
buffer size.
The length parameter passed to utf16_to_utf8() would include the terminator, so
the converted string would end up with two terminators (the original one
converted to "utf8", still 0, and then the one that was always added anyway).
Instead let's pass just the length of the actual data to utf16_to_utf8().
The test queries some domain names. If the DNS servers are unreachable,
e.g. in a rawhide container I get the total runtime of 24.5s usually, but
sometimes slightly longer, enough to reach the default timeout of 30s.
gcc-9 warns:
../src/test/test-util.c:147:19: note: in expansion of macro ‘container_of’
147 | assert_se(container_of(&myval.v1, struct mytype, v1) == &myval);
| ^~~~~~~~~~~~
I don't think packing matters here for the test of container_of(), so let's
just remove it.
gcc-9 warns whenever the elements of a structure defined with _packed_ are used:
../src/network/networkd-dhcp6.c: In function ‘dhcp6_pd_prefix_assign’:
../src/network/networkd-dhcp6.c:92:53: warning: taking address of packed member of ‘struct <anonymous>’ may result in an unaligned pointer value [-Waddress-of-packed-member]
92 | r = manager_dhcp6_prefix_add(link->manager, &p->opt.in6_addr, link);
| ^~~~~~~~~~~~~~~~
And the compiler is right, because in principle the alignment could be wrong.
In this particular case it is not, because the structure is carefully defined
not to have holes. Let's remove _packed_ and use compile-time asserts to verify
that the offsets are not changed.
When `syscall_names_in_filter()` is called in itself, it is already
examined with `whitelist`. Or, in other words, `syscall_names_in_filter()`
returns bad or good in boolean. So, the returned value should not be
compared with `whitelist` again.
This replaces #11302.
internal_hashmap_first_key_and_value() returns the first value, or %NULL
if the hashmap is empty.
However, hashmaps may contain %NULL values. That means, a caller getting
%NULL doesn't know whether the hashmap is empty or whether the first
value is %NULL.
For example, a caller may be tempted to do something like:
if ((val = hashmap_steal_first_key_and_value (h, (void **) key))) {
// process first entry.
}
But this is only correct if the caller made sure that the hash is either
not empty or contains no NULL values.
Anyway, since a %NULL return value can signal an empty hash or a %NULL
value, it seems error prone to leave the key output argument
uninitialized in situations that the caller cannot clearly distinguish
(without making additional assumptions).
GCC 8.2 with LTO and -O2 emits a false warning:
src/basic/hashmap.c: In function 'internal_hashmap_free.constprop':
src/basic/hashmap.c:898:33: error: 'k' may be used uninitialized in this function [-Werror=maybe-uninitialized]
free_key(k);
^
Avoid it by initializing the variable.
I had accidentally filled my /var partition. This caused backlight to fail to
start even with disk space, because the brightness files were truncated to zero
size:
systemd-backlight[624]: acpi_video0: Failed to parse brightness "": Invalid argument
systemd-backlight[624]: acpi_video0: Failed to write system 'brightness' attribute: No such device or address
systemd[1]: systemd-backlight@backlight:acpi_video0.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: systemd-backlight@backlight:acpi_video0.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0.
Handle a truncated file like non-existent file.
Too much code has been removed while replacing startswith with STARTSWITH_SET
so that every ACL specified e.g. in tmpfiles.d was parsed as a default ACL.
Originally commented as "devices names might have changed/swapped in the meantime",
but may not. For safety, let's block the following events with same
devpath.
This may fix#6514.
We could potentially create an unterminated string and then call normal string
operations on it. Let's be more careful: first remove the suffix we ignore anyway,
then find if the string is of acceptable length, and possibly ignore it if it
is too long. The code rejects lengths above 31 bytes. Language names that are
actually used are much shorter, so this doesn't matter much.
* kernel-install: fix initrd when called as installkernel
Running make install from the kernel runs e.g.:
installkernel 4.20.5 arch/x86/boot/bzImage System.map "/boot"
Since 0912c0b80e this would
cal 90-loaderentry.install with those arguments:
add 4.20.5 /boot/... arch/x86/boot/bzImage System.map "/boot"
The two last arguments would then be handled as the initrd files.
As System.map exists in current directory but not in /boot/...
it would get copied there, and used as initrd intead of the initrd
which has been generated by dracut.
With this change, nothing changes when kernel-install is called
directly, but when it's called as installkernel, we now pass
thos arguments to 90-loaderentry.install:
add 4.20.5 /boot/... arch/x86/boot/bzImage initrd
initrd is thus detected as the file to use for the initrd, and as it
exists, nothing is copied over and the initrd line generated is
consistent with what one would expect
* kernel-install: fix dracut initrd detection when called directly
This brings back the systemd 240 behaviour when called directly too
* kernel-install: unify initrd fallback
* kernel-install: move initrd fallback handling to 90-loaderentry.install
* kernel-install: move initrd fallback just before creating loader entry
gcc-9 complains that the string may be truncated when written into the output
structure. This shouldn't happen, but if it did, in principle we could remove a
different structure (with a matching name prefix). Let's just refuse the
operation if the name doesn't fit.
Of course, this should never happen, but let's better be safe than
sorry, and abort rather than continue when a too large memory block is
allocated, simply asa safety precaution.
An early abort is better than continuing with a likely memory corruption
later.
The problem was introduced in a37422045fbb68ad68f734e5dc00e0a5b1759773:
we have a unit which has a fragment, and when we'd update it based on
/proc/self/mountinfo, we'd say that e.g. What=/dev/loop8 has origin-fragment.
This commit changes two things:
- origin-fragment is changed to origin-mountinfo-implicit
- when we stop a unit, mountinfo information is flushed and all deps based
on it are dropped.
The second step is important, because when we restart the unit, we want to
notice that we have "fresh" mountinfo information. We could keep the old info
around and solve this in a different way, but keeping stale information seems
inelegant.
Fixes#11342.
In normal use, this allow us to drop dead entries from the cache and reduces
the cache size so that we don't evict entries unnecessarily. The time limit is
there mostly to serve as a guard against malicious logging from many different
PIDs.
This is far from perfect, but should give mostly reasonable values. My
assumption is that if somebody has a few hundred MB of memory, they are
unlikely to have thousands of processes logging. A hundred would already be a
lot. So let's scale the cache size propritionally to the total memory size,
with clamping on both ends.
The formula gives 64 cache entries for each GB of RAM.
First of all let's always log where the errors happen, and not in an
upper stackframe, in all cases. Previously we'd do this somethis one way
and sometimes another, which resulted in sometimes duplicate logging and
sometimes none.
When we cannot activate something due to bad password the kernel gives
us EPERM. Let's uniformly return this EAGAIN, so tha the next password
is tried. (previously this was done in most cases but not in all)
When we get EPERM let's also explicitly indicate that this probably
means the password is simply wrong.
Fixes: #11498
procfs_memory_get_current is renamed to procfs_memory_get_used, because
"current" can mean anything, including total memory, used memory, and free
memory, as long as the value is up to date.
No functional change.
