Let's not leak details from src/shared and src/libsystemd into
src/basic, even though you can't actually do anything useful with
just forward declarations from src/shared.
The sd-forward.h header is put in src/libsystemd/sd-common as we
don't have a directory for shared internal headers for libsystemd
yet.
Let's also rename forward.h to basic-forward.h to keep things
self-explanatory.
Let's use libarchive consistently everywhere, both for tarring and
untarring.
Note that there's an existing test case that validates untarring. Now,
it will validate libarchive rather than gnu tar.
Split out of #38728
This reverts commit e1e1ef09f9.
This change was misguided. The warning is enough during development and will
get fixed, but turning this into a hard failure just makes WIP harder. Also, a
hard error increases the likelyhood of a build failure in scenarios where
somebody is disabling components (as seen e.g. in
ba8801a076). We already are not very good at
keeping our codebase compile correctly as it ages, because of changes in
compilers and dependencies, and we should not go out of our way to increase the
probability of failure. Such scenarios are painful for downstream builds.
We dropped support for split-usr a while ago, which means that the programs
will be in /usr/sbin, which actually may be the same as /usr/bin on merged-bin
systems. So the whole checking is mostly pointless in the usual case. OTOH, on
Nix the paths will be totally different and need to be set through the option
anyway. So save time during builds by using the "fallback" path unless the
option is specified.
This avoid some busywork during the slow serial build phase.
This way we have can expose identical behaviour everywhere, can make use
of our atomic replacement calls, and openat() logic, and later apply
additional tracks while unpacking, such as putting limits on UID ranges
and similar.
Most of those were dropped in 7d247d3cb8. I left
behind the few cases where the 'output' name was different from the target name.
But we actually don't need those either, so get rid of those. (And one case
where I missed the name argument.)
No functional change, except that e.g. 'ninja -C build update-man-rules-impl'
doesn't work, but I hope nobody was using that.
Those were added before 0.61 which is our minimum version.
Dots were dropped from the end of some messages. Most messages did not have the
trailing dot.
0.63 added support for multi-line f-strings. We can't use those yet.
It helps nobody to break compatibility for a missing definition
for printing an error.
Just add the missing definition if not present, as it is already
done for thousands of others from the kernel, glibc, etc.
This partially reverts commit d8b60944f5.
This is also preparation for the installer later, split out of #38764.
It makes the experience a lot nicer if our nice little tools aren't
constantly interrupted by log spew from the kernel.
Fixes: #34448
For "wizard" style interactive tools it's very annoying if they are
interrupted by kernel log output or PID1's status output. let's add some
infra to disable this temporarily. I decided to implement this as an IPC
service so that we can make this robust: if the client request the
muting dies we can automatically unmute again.
This is hence a tiny varlink service, but it can also be started
directly from the cmdline.
I initially didn't think it would be worth doing this, but I changed my
mind. People out there quite successfully build systemd without ACL
support, and that suggests life without it is quite possible. Moreover
we only use it as very specific places:
1. in udev/logind for "uaccess" mgmt
2. in tmpfiles to implement explicitly configured acl changes
3. in journald/coredump/pstore to manage access to unpriv users
4. in pid1 to manage access to credential files
5. when shifting UIDs of container trees
I specific container environments it should be entirely fine to live without all
of these, hence let's pull this in on demand only.
Major distributions already have libfido2 >= 1.12.0. Let's bump the
required minimum version to 1.5.0, which provides FIDO_ERR_UV_BLOCKED.
Note, libfido2 1.5.0 was released on 2020-09-01.
See also #38608.
Major distributions already have libfido2 >= 1.12.0.
Let's bump the required minimum version to 1.5.0, which provides
FIDO_ERR_UV_BLOCKED.
Note, libfido2 1.5.0 was released on 2020-09-01.
See also #38608.
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able to have
it in /nix/store too like the other util-linux tools).
Given that `unmerged-usr` support was dropped in 255 I think this is a
safe change?
There is a botched arm64 linker transition going on, where a new feature
is enabled (GCS) and the linker fails the build unless all object files
being linked are built with the new specific feature. This was enabled
in the toolchain (GCC 15) _before_ all libraries were rebuilt, including
glibc, so everything fails. The toolchain maintainers declined to fix it
and instead say that this is a useless warning to have, and to just
disable it and ignore it.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1110461
> systemd fails to build from source on arm64 if built with GCC-15, currently in
> experimental.
>
> GCC-15 includes support for an arm64 security feature called Guarded Control
> Stack (GCS). To help with GCS adoption, the linker warns about shared libraries
> built without GCS. For example:
>
> /usr/lib/gcc/aarch64-linux-gnu/15/../../../aarch64-linux-gnu/libncursesw.so.6:
> warning: GCS is required by -z gcs, but this shared library lacks the necessary property note.
> The dynamic loader might not enable GCS or refuse to load the program unless
> all the shared library dependencies have the GCS marking.
>
> The warning is harmless, and can be ignored. However, systemd is built with
> --fatal-warnings, and for this reason will fail to build on arm64 once GCC-15
> becomes the default compiler in Debian.
[585/3230] Linking target src/core/libsystemd-core-258.so
FAILED: src/core/libsystemd-core-258.so
gcc -o src/core/libsystemd-core-258.so -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,-soname,libsystemd-core-258.so -Wl,--whole-archive -Wl,--start-group src/core/libsystemd-core-258.a -Wl,--no-whole-archive -fstack-protector -Wl,-z,relro -specs=/usr/share/debhelper/dh_package_notes/debian-package-notes.specs -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/work/src=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard -O0 -g -Og -Wdate-time '-Wl,-rpath,$ORIGIN/../shared' src/shared/libsystemd-shared-258.so -shared -Wl,--version-script=/work/src/src/shared/libshared.sym /usr/lib/aarch64-linux-gnu/libacl.so /usr/lib/aarch64-linux-gnu/libaudit.so /usr/lib/aarch64-linux-gnu/libblkid.so -ldl -lm /usr/lib/aarch64-linux-gnu/libmount.so -lrt /usr/lib/aarch64-linux-gnu/libseccomp.so /usr/lib/aarch64-linux-gnu/libselinux.so -Wl,--end-group -pthread -Wl,--fatal-warnings -Wl,-z,now -Wl,-z,relro -Wl,--gc-sections -Wl,--warn-common
src/shared/libsystemd-shared-258.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libacl.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libaudit.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libblkid.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libm.so.6: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libmvec.so.1: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libmount.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libseccomp.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/usr/lib/aarch64-linux-gnu/libselinux.so: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/aarch64-linux-gnu/libc.so.6: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
/lib/ld-linux-aarch64.so.1: warning: GCS is required by -z gcs, but this shared library lacks the necessary property note. The dynamic loader might not enable GCS or refuse to load the program unless all the shared library dependencies have the GCS marking.
collect2: error: ld returned 1 exit status
I noticed in our NixOS packaging that we were working around the fact
that core/swap.c looks for swapon and swapoff in /sbin
Lets make it configurable just like all the other util-linux binaries
through meson and make it default to /usr/sbin/{swapon,swapoff}
This way mounts work on a systemd without the /sbin -> /usr/sbin
compatibility symlink. (And as a side-effect has NixOS be able
to have it in /nix/store too like the other util-linux tools).
bpf_loop() and bpf_strncmp(), used by sysctl-monitor, were introduced
in libbpf 0.7, so skip the module if using an older version
Follow-up for 6d9ef22acd
We went back and forth between 'prog.sh', files('prog.sh'), and
find_program('prog.sh'). We want to use files() or find_program() so that we
get a good error message if the file is missing. Behaviour of meson changed
over time, and in the past not all forms could be used in all places. For
example 0f4c4f3824 added find_program() in many
places to avoid repeated messages. But it seems that all recent meson versions
work fine with files().
find_program prints silly messages:
Program tools/make-man-index.py found: YES
(/home/zbyszek/src/systemd/tools/make-man-index.py)
Program tools/meson-render-jinja2.py found: YES
(/home/zbyszek/src/systemd/tools/meson-render-jinja2.py)
...
We know that those files will be found, they are part of the git checkout.
With files() this is gone and the meson output is easier to read.
On 64-bit POWER, there are multiple versions of the ELF ABI in use.
- little-endian powerpc64 is ELFv2
- big-endian powerpc64 is
- ELFv2 when using musl
- either ELFv1 or ELFv2 when using glibc
Previously, the BPF build was hard-coding `-D_CALL_ELF=2`, which is
ELFv2. This makes the build fail on ELFv1, similarly to the original
issue that necessitated the addition of this flag on powerpc64le.
To fix this:
1. Use ELFv1 as the default (when `_CALL_ELF` is not defined, this is
the assumption that should be made about the ABI version).
2. Check if the C compiler has `_CALL_ELF` defined, and if it does,
override the default with that.
That's technically not the *correct* compiler in this situation, but I'm
unsure how to get a compiler object for the BPF one from Meson to do the
`*_define('_CALL_ELF')` checks with, and they *should* both be targeting
the same ABI version anyway.
3. Add the ABI version to the `_CALL_ELF` definition for the BPF
compiler flags.
This makes a BPF-enabled build succeed on powerpc64 w/ ELFv1 glibc.
We require at least crypt_r() exists, and it is provided since glibc-2.0
(and dropped in glibc-2.39) or by libxcrypt, and the function is
provided in crypt.h regardless it is provided by glibc or libxcrypt.
Hence, we cannot fallback to unistd.h.
This makes the condition about crypt.h more strict, and stop compilation
earlier when crypt.h does not exist.
This moves coverage.h to src/coverage/, and specifies path to coverage.h
with files() directive, to make it can be included even when located
outside of the include directories. Otherwise, libc-wrapper cannot be
built when -Db_coverage=true option is enabled.
Follow-up for 543a48b653.
Then, move syscall definitions to the wrapper, and prototypes are moved
to relevant headers.
This also adds checks for add_key() and request_key(), as one day
glibc may be going to add some of them separatedly.
The check for fspick in meson.build is dropped, as it is currently
unused in our code.
This also moves
- basic/missing_bpf.h -> include/override/linux/bpf.h,
- basic/missing_keyctl.h -> include/override/linux/keyctl.h.
- pass our system include directories to make generators use our libc
wrappers and latest kernel headers,
- include relevant headers in generated gperf file,
- use files() rather than find_program(), as the result of
find_program() cannot be passed to 'input' of custom_target(),
- move generate-bpf-delegate-configs.py to src/core/, as it is only used
by libcore.
I added them in 41afb5eb72 without too
much explanation. Most likely the idea was to get rid of unused code
in libsystemd.so [1]. But now that I'm testing this, it doesn't seem
to have an effect. LTO is needed to get rid of unused functions, and
it's enough to have LTO without those options. Those options might have
some downsides [2], so let's disable them since there are doubts and no
particularly good reason to have them.
But keep the -Wl,--gc-sections option. Without this, libsystemd.so
grows a little:
-rwxr-xr-x 1 zbyszek zbyszek 5532424 07-08 13:24 build/libsystemd.so.0.40.0-orig
-rwxr-xr-x 1 zbyszek zbyszek 5614472 07-08 13:26 build/libsystemd.so.0.40.0-no-sections
-rwxr-xr-x 1 zbyszek zbyszek 5532392 07-08 13:27 build/libsystemd.so.0.40.0
Let's apply the --gc-sections option always to make the debug and final
builds more similar.
We need to verify that distro packages don't unexpectedly grow after this.
[1] https://unix.stackexchange.com/a/715901
[2] https://stackoverflow.com/a/36033811
Currently, when running "systemctl preset-all --root=xxx" in mkosi
to enable/disable units for initrds, the system presets are used.
The problem with this approach is that the system presets are written
for the system, and that is not necessarily ideal for an initrd, but we
still want to use the same packages in the initrd that we install in the
system, so let's introduce a separate directory for initrd presets which
is used to pick up preset files from when we detect that we're configuring
an initrd (by looking for /etc/initrd-release).
We also introduce a systemd preset file for the initrd, which is based on
the system one, except with all the stuff unnecessary for the initrd removed.
