This gets enabled by default in gcc-14 and complains everywhere where we
use assert() on an expression that is always true (i.e. using
`int x[static 2]` in function declaration, etc.):
[153/2414] Compiling C object src/basic/libbasic.a.p/fs-util.c.o
In file included from ../src/basic/macro.h:13,
from ../src/basic/alloc-util.h:10,
from ../src/basic/fs-util.c:11:
../src/basic/fd-util.h: In function ‘format_proc_fd_path’:
../src/fundamental/macro-fundamental.h:74:41: warning: ‘nonnull’ argument ‘buf’ compared to NULL [-Wnonnull-compare]
74 | #define _unlikely_(x) (__builtin_expect(!!(x), 0))
| ^~~~~
../src/basic/macro.h:150:21: note: in expansion of macro ‘_unlikely_’
150 | if (_unlikely_(!(expr))) \
| ^~~~~~~~~~
../src/basic/macro.h:167:22: note: in expansion of macro ‘assert_message_se’
167 | #define assert(expr) assert_message_se(expr, #expr)
| ^~~~~~~~~~~~~~~~~
../src/basic/fd-util.h:129:9: note: in expansion of macro ‘assert’
129 | assert(buf);
| ^~~~~~
Disabling this selectively only for asserts is a bit painful, since the
option is not available in all compilers, and it'd need to be handled in
the EFI stuff as well.
This adds a tiny binary that is hooked into SSH client config via
ProxyCommand and which simply connects to an AF_UNIX or AF_VSOCK socket
of choice.
The syntax is as simple as this:
ssh unix/some/path # (this connects to AF_UNIX socket /some/path)
or:
ssh vsock/4711
I used "/" as separator of the protocol ID and the value since ":" is
already taken by SSH itself when doing sftp. And "@" is already taken
for separating the user name.
ukify (and all the tests, including the autogenerated check-version-ukify)
does not work unless pefile is available, so track it as a dependency
in meson to avoid unit test failures later
This make them recognized by file managers and stuff. Maybe one day we
should properly register mime types in the "vnd." namespace with IANA,
but I am too lazy to deal with the bureaucracy for that, hence let's
stick with the x. namespace for now.
This defines confext/sysext DDIs as subtype of:
https://www.iana.org/assignments/media-types/application/vnd.efi.img
Which is what everyone appears to use for raw disk images, in particular
if they contain a GPT partition table.
sshd now supports config file drop-ins, hence let's install one to hook
up "userdb ssh-authorized-keys", so that things just work.
We put the drop-in relatively early, so that other drop-ins generally
will override this.
Ideally sshd would support such drop-ins in /usr/ rather than /etc/, but
let's take what we can get. It's not that sshd's upstream was
particularly open to weird ideas from Linux people.
The meson summary logic checks for ENABLE_* and HAVE_*, but we used a define
with no prefix. Let's make it ENABLE_… for consistency with other config
options. Obviously this also fixes the summary output.
This should also implicitly enabled vmspawn in CI. It wasn't passing even the
basic tests, which we didn't see, because it needs to be explicitly enabled.
This implements a "storage target mode", similar to what MacOS provides
since a long time as "Target Disk Mode":
https://en.wikipedia.org/wiki/Target_Disk_Mode
This implementation is relatively simple:
1. a new generic target "storage-target-mode.target" is added, which
when booted into defines the target mode.
2. a small tool and service "systemd-storagetm.service" is added which
exposes a specific device or all devices as NVMe-TCP devices over the
network. NVMe-TCP appears to be hot shit right now how to expose
block devices over the network. And it's really simple to set up via
configs, hence our code is relatively short and neat.
The idea is that systemd-storagetm.target can be extended sooner or
later, for example to expose block devices also as USB mass storage
devices and similar, in case the system has "dual mode" USB controller
that can also work as device, not just as host. (And people could also
plug in sharing as NBD, iSCSI, whatever they want.)
How to use this? Boot into your system with a kernel cmdline of
"rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on
screen the precise "nvme connect" command line to make the relevant
block devices available locally on some other machine. This all requires
that the target mode stuff is included in the initrd of course. And the
system will the stay in the initrd forever.
Why bother? Primarily three use-cases:
1. Debug a broken system: with very few dependencies during boot get
access to the raw block device of a broken machine.
2. Migrate from system to another system, by dd'ing the old to the new
directly.
3. Installing an OS remotely on some device (for example via Thunderbolt
networking)
(And there might be more, for example the ability to boot from a
laptop's disk on another system)
Limitations:
1. There's no authentication/encryption. Hence: use this on local links
only.
2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd
have a read-only mode, for security reasons, and default to it.
Future love:
1. We should have another mode, where we simply expose the homed LUKS
home dirs like that.
2. Some lightweight hookup with plymouth, to display a (shortened)
version of the info we write to the console.
To test all this, just run:
mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
Follow-up for 8b45281daa
and preparation for later commits.
Since libcs are more interested in the POSIX `fchmodat(3)`, they are
unlikely to provide a direct wrapper for this syscall. Thus, the headers
we examine to set `HAVE_*` are picked somewhat arbitrarily.
Also, hook up `try_fchmodat2()` in `test-seccomp.c`. (Also, correct that
function's prototype, despite the fact that mistake would not matter in
practice)
Co-authored-by: Mike Yuan <me@yhndnzj.com>
This allows distros to install configuration file templates in /usr/lib/systemd
for example.
Currently we install "empty" config files in /etc/systemd/. They serve two
purposes:
- The file contains commented-out values that show the default settings.
- It is easier to edit the right file if it is already there, the user doesn't
have to type in the path correctly, and the basic file structure is already in
place so it's easier to edit.
Things that have happened since this approach was put in place:
- We started supporting drop-ins for config files, and drop-ins are the
recommended way to create local configuration overrides.
- We have systemd-analyze cat-config which takes care of iterating over
all possible locations (/etc, /run, /usr, /usr/local) and figuring out
the right file.
- Because of the first two points, systemd-analyze cat-config is much better,
because it takes care of finding all the drop-ins and figuring out the
precedence. Looking at files manually is still possible of course, but not
very convenient.
The disadvantages of the current approach with "empty" files in /etc:
- We clutter up /etc so it's harder to see what the local configuration actually is.
- If a user edits the file, package updates will not override the file (e.g.
systemd.rpm uses %config(noreplace). This means that the "documented defaults"
will become stale over time, if the user ever edits the main config file.
Thus, I think that it's reasonable to:
- Install the main config file to /usr/lib so that it serves as reference for
syntax and option names and default values and is properly updated on package
upgrades.
- Recommend to users to always use drop-ins for configuration and
systemd-analyze cat-config to view the documentation.
This setting makes this change opt-in.
Fixes#18420.
[zjs: add more text to the description]
We were testing the that C constant is defined, but we weren't actually testing
that the string name maps back to itself. This would catch the issue fixed by
the grandparent commit.
The test for the default name is moved to the test file to keep the tests
together. The define is renamed to not have "_TEST" in the name. The issue here
is complicated by the fact that we allow downstreams to inject additional
fields, so we don't know the name of the default scheme if it not set with
-Ddefault-net-naming-scheme=, so _DEFAULT_NET_NAMING_SCHEME[_TEST] is not
defined in all cases, but at least in principle it could be used in other
places. If it exists, it is fully valid.
Currently we spawn services by forking a child process, doing a bunch
of work, and then exec'ing the service executable.
There are some advantages to this approach:
- quick: we immediately have access to all the enourmous amount of
state simply by virtue of sharing the memory with the parent
- easy to refactor and add features
- part of the same binary, will never be out of sync
There are however significant drawbacks:
- doing work after fork and before exec is against glibc's supported
case for several APIs we call
- copy-on-write trap: anytime any memory is touched in either parent
or child, a copy of that page will be triggered
- memory footprint of the child process will be memory footprint of
PID1, but using the cgroup memory limits of the unit
The last issue is especially problematic on resource constrained
systems where hard memory caps are enforced and swap is not allowed.
As soon as PID1 is under load, with no page out due to no swap, and a
service with a low MemoryMax= tries to start, hilarity ensues.
Add a new systemd-executor binary, that is able to receive all the
required state via memfd, deserialize it, prepare the appropriate
data structures and call exec_child.
Use posix_spawn which uses CLONE_VM + CLONE_VFORK, to ensure there is
no copy-on-write (same address space will be used, and parent process
will be frozen, until exec).
The sd-executor binary is pinned by FD on startup, so that we can
guarantee there will be no incompatibilities during upgrades.
This reverts commit 0e3cc902fa.
Fixes#10288.
I have confirmed that this does now fix cross-compilation.
It appears that changes upstream in Meson, probably mesonbuild/meson#5263, have made the original MR, #10289, work now.
This needs to be tested to ensure that it doesn't break Travis CI like when it was reverted in #10361.
This changes the doc-sync meson target from a simple rsync command to a
script that:
* puts the documentation in a subdirectory according to the version
* injects a bit of javascript to add a drop-down to switch between versions
* updates an index.json file with the newly uploaded version
* keeps the latest/ directory up to date with the latest version
* supports a --no-latest switch to be used when uploading older versions
This adds --make-ddi=confext, --make-ddi=sysext, --make-ddi=portable, to
make it really easiy to generate DDIs of the specified class. It
it's ultimately just a fancy wrapper around some defaults and in
particular --definitions=.
This makes it very easy to generate a confext:
$ systemd-repart -C --private-key=privkey.pem --certificate=cert.crt -s mytree/ mytree.confext.raw
This adds a new script tools/check-version-history.py and a corresponding
test when building in developer mode. It checks manpages (except dbus
documentation which is handled by update-dbus-docs) for missing version
history information.
It also adds ignore lists based on version 183 (the version that our version
annotations go back to). These can be augmented if we want to ignore other
elements if it doesn't make sense for them to have version annotations.
This adds an explicit service for initializing the TPM2 SRK. This is
implicitly also done by systemd-cryptsetup, hence strictly speaking
redundant, but doing this early has the benefit that we can parallelize
this in a nicer way. This also write a copy of the SRK public key in PEM
format to /run/ + /var/lib/, thus pinning the disk image to the TPM.
Making the SRK public key is also useful for allowing easy offline
encryption for a specific TPM.
Sooner or later we should probably grow what this service does, the
above is just the first step. For example, the service should probably
offer the ability to reset the TPM (clear the owner hierarchy?) on a
factory reset, if such a policy is needed. And we might want to install
some default AK (?).
Fixes: #27986
Also see: #22637
The main reason we need to apply a whole lot of logic to the section
conversion logic is because PE sections have to be aligned to the page
size (although, currently not even EDK2 enforces this). The process of
achieving this with a linker script is fraught with errors, they are a
pain to set up correctly and suck in general. They are also not
supported by mold, which requires us to forcibly use bfd, which also
means that linker feature detection is easily at odds as meson has a
differnt idea of what linker is in use.
Instead of forcing a manual ELF segment layout with a linker script we
just let the linker do its thing. We then simply copy/concatenate the
sections while observing proper page boundaries.
Note that we could just copy the ELF load *segments* directly and
achieve the same result. Doing this manually allows us to strip sections
we don't need at runtime like the dynamic linking information (the
elf2efi conversion is effectively the dynamic loader).
Important sections like .sbat that we emit directly from code will
currently *not* be exposed as individual PE sections as they are
contained within the ELF segments. A future commit will fix this.
Build targets should have a link dependency on the version scripts they
use. This also uses absolute paths in anticipation for meson 1.3
needlessly deprecating file to string conversions.
This was requested, though I think an issue was never filed. If people are
supposed to invoke it, even for testing, then it's reasonable to make it
"public".
The tool initially just measured the boot phase, but was subsequently
extended to measure file system and machine IDs, too. At AllSystemsGo
there were request to add more, and make the tool generically
accessible.
Hence, let's rename the binary (but not the pcrphase services), to make
clear the tool is not just measureing the boot phase, but a lot of other
things too.
The tool is located in /usr/lib/ and still relatively new, hence let's
just rename the binary and be done with it, while keeping the unit names
stable.
While we are at it, also move the tool out of src/boot/ and into its own
src/pcrextend/ dir, since it's not really doing boot related stuff
anymore.
Installing ukify.py doesn't require a working UEFI architecture, but
only that the bootloader option is enabled (and python3). On Debian
Arch: all packages (like python scripts) can theorethically be built
on any builder with any architecture, so there's no guarantee that
it will actually be an EFI-enabled architecture to do that package build.
Relax the requirement to check only for the ukify config option.
This conceptually reverts e95acdfe1d,
but the actual contents of the script are taken from the command invocation
in meson with all the updates that happened in the meantime.
One small change is that I replaced () by {}: this avoids one subprocess spawn.
People were worried about the cost of vcs_tag(), and this microoptimization may
help a bit. I measured the speed on machine, and noop rebuilds are still about
100–120 ms.
The logic is entirely moved to the script. This makes the meson config simpler
and also makes it easier to use it externally.
The script is needed for in-place rpm builds, see README.build-in-place.md [1],
where it is invoked from the spec file to determine the project version.
[1] https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/README.build-in-place.md
The name is created as "systemd:fuzz / fuzz-<fuzzer_name>_<sample_name>"
and if that's very long, output gets wrapped when 'meson test' is run, and
this is rather annoying.
Disallow filenames above 45 characters, which leads a 60 char names.
The notice in the man page is removed and the tool is moved into the $PATH.
A compat symlink is provided.
It is fairly widely used now, and realistically we need to keep backwards
compat or people will be very unhappy.
This partially reverts 3c1eee5bed.
I thought that it is not necessary, but
https://mesonbuild.com/Reference-manual_functions.html#vcs_tag says:
> This method returns a custom_tgt should be used to signal dependencies if
> other targets use the file outputted by this.
>
> For example, if you generate a header with this and want to use that in a
> build target, you must add the return value to the sources of that build
> target. Without that, Meson will not know the order in which to build the
> targets.
We can use version_h directly, since we already have it.
Hopefully fixes https://github.com/systemd/systemd/issues/28994.
