unit: add units for new "systemd-sysupdate" tool

These unit (if enabled) will try to update the OS in regular intervals.
Moreover, every day in the early morning this will attempt to reboot the
system if there's a newer version installed than running.

sysupdate: add new component "sysupdate"

various: make parse_env_file error handling the same in various places

No big reason to do this, except that I was looking at all call sites
and it's nicer if the same style is used accross the codebase.

boot: Draw unicode separator line for status messages

Merge pull request #22519 from poettering/boot-order-title-revert

sd-boot: rework boot entry sorting

strv: use STRV_FOREACH() at two more places

strv: rewrite strv_copy() with cleanup attribute and STRV_FOREACH()

time-util: add macros around timespec_store() that operates on compund literal allocated timespec struct

This way we can convert usec_t to timespec on-the-fly, without a buffer.

No actual behaviour change just some shortening of code.

shell-completion: Add completion for oomctl

Added bash and zsh completions for oomctl arguments and commands.

Related To: #22118

Merge pull request #22787 from poettering/bootspec-split

shared: split bootspec.c in two

Add HP Elitebook 2760p support (#22766)

meson: sort shared source file list again

shared: split out ESP/XBOOTLDR search stuff from bootspec.c

The code is quite different from the rest of bootspec.c, with different
deps and stuff. There's even a /***/ line to separate the two parts.
Given how large the file already is, let#s just split it into two.

No code changes, just some splitting out.

update TODO

test: add test that verifies correct order of boot entries

kernel-install: automatically generate "sort-key" field

Let's order by IMAGE_ID=/ID= by default.

sd-boot: add comments highlighting type 1 vs. type 2

sd-boot: make use of new "sort-key" boot loader spec field

docs: add new "sort-key" field to boot loader spec

This allows snippet generators to explicitly order entries: any string
can be set as an entry's "sort key". If set, sd-boot will use it to sort
entries on display.

New logic is hence (ignore the boot counting logic)

  sort-key is set → primary sort key: sort-key (lexicographically increasing order)
                  → secondary sort key: machine-id (also increasing order)
                  → tertiary sort key: version (lexicographically decreasing order!)

  sort-key is not set → primary sort key: entry filename (aka id), lexicographically increasing order)

With this scheme we can order OSes by their names from A-Z but then put
within the same OS still the newest version first. This should clean up
the order to match expectations more.

Based on discussions here:

https://github.com/systemd/systemd/pull/22391#issuecomment-1040092633

Revert "boot: Change boot entry sorting"

This reverts commit 9818ec8ea56e14902ac8e548a0f366dbb259f051.

doc: mention that setfsuid() is a reason why UIDs >= 2147483648 are icky

Merge pull request #22784 from poettering/bootctl-fixlets

Trivial bootctl/kernel-install fixlets

systemctl: fix operations on relative paths

We should treat ./some.service and $PWD/some.service as equivalent. But we'd
try to send the relative paths over dbus, which can't work well:

$ sudo systemctl enable ./test2.service
Failed to look up unit file state: Invalid argument
$ sudo systemctl enable $PWD/test2.service
Created symlink /etc/systemd/system/multi-user.target.wants/test2.service → /home/zbyszek/src/systemd/test2.service.
Created symlink /etc/systemd/system/test2.service → /home/zbyszek/src/systemd/test2.service.

Now both are equivalent.

shared/install-printf: drop now-unused install_path_printf()

shared/install: do not print aliases longer than UNIT_NAME_MAX

065364920281e1cf59cab989e17aff21790505c4 did the conversion to install_path_printf().
But IIUC, here we are just looking at a unit file name, not the full
path.

basic/env-file: inline one variable declaration

systemctl: remove unused parameter

systemctl: drop left-over parens

man/systemd.exec: tweak markup a bit

shared/install: adjust comment formatting

tree-wide: use strv_contains() in more places

shared/install: drop unnecessary casts

The compiler coerces to bool for us, no need to do it explicitly.

shared/install: drop unnecessary parentheses

shell-completion: Add completion in bootctl

Added new completion for `--make-machine-id-directory`
provideds 3 options(yes no auto)

Closes: #22308

shared/install: consistently use 'lp' as the name for the LookupPaths instance

Most of the codebase does this. Here we were using 'p' or 'paths'
instead. Those names are very generic and not good for a "global-like"
object like the LookupPaths instance. And we also have 'path' variable,
and it's confusing to have 'path' and 'paths' in the same function that
are unrelated.

Also pass down LookupPaths* lower in the call stack, in preparation for
future changes.

Add tests and documentation for all remaining sandboxing in user manager

core: insist on sandboxing if ExtensionImages/Directories are configured

Same as other image mounting in the namespace

sd-device: shorten code a bit

sd-device-enumerator: fix typo: contolC -> controlC

Also shorten code a bit.

sort-util: add missing parens

With this, we can call e.g.
```
typesafe_qsort(buf + m, n - m, comp);
```

bootctl: add comment, explaining when verb_install() is called

bootctl: use faccessat() more

bootctl: fix typo

kernel-install: drop spurious double empty line

kernel-install: make clear which variables are supposed to be placed in install.conf in a comment

Merge pull request #22754 from mrc0mmand/creds_dir_specifier

core: add %d specifier for the $CREDENTIALS_DIRECTORY

tree-wide: fix duplicated words

the the
in in
not not
we we

Merge pull request #22752 from yuwata/udev-ctrl-manage-sender-pids

udev: enable Delegate=

Merge pull request #22774 from poettering/nspawn-uidmap-fix

nspawn: uidmap mount fix

homed: permit inodes owned by UID_MAPPED_ROOT to be created in $HOME

If people use nspawn in their $HOME we should allow this inodes owned by
this special UID to be created temporarily, so that UID mapped nspawn
containers just work.

nspawn: make sure host root can write to the uidmapped mounts we prepare for the container payload

When using user namespaces in conjunction with uidmapped mounts, nspawn
so far set up two uidmappings:

1. One that is used for the uidmapped mount and that maps the UID range
   0…65535 on the backing fs to some high UID range X…X+65535 on the
   uidmapped fs. (Let's call this mapping the "mount mapping")

2. One that is used for the userns namespace the container payload
   processes run in, that maps X…X+65535 back to 0…65535. (Let's call
   this one the "process mapping").

These mappings hence are pretty much identical, one just moves things up
and one back down. (Reminder: we do all this so that the processes can
run under high UIDs while running off file systems that require no
recursive chown()ing, i.e. we want processes with high UID range but
files with low UID range.)

This creates one problem, i.e. issue #20989: if nspawn (which runs as
host root, i.e. host UID 0) wants to add inodes to the uidmapped mount
it can't do that, since host UID 0 is not defined in the mount mapping
(only the X…X+65536 range is, after all, and X > 0), and processes whose
UID is not mapped in a uidmapped fs cannot create inodes in it since
those would be owned by an unmapped UID, which then triggers
the famous EOVERFLOW error.

Let's fix this, by explicitly including an entry for the host UID 0 in
the mount mapping. Specifically, we'll extend the mount mapping to map
UID 2147483646 (which is INT32_MAX-1, see code for an explanation why I
picked this one) of the backing fs to UID 0 on the uidmapped fs. This
way nspawn can creates inode on the uidmapped as it likes (which will
then actually be owned by UID 2147483646 on the backing fs), and as it
always did. Note that we do *not* create a similar entry in the process
mapping. Thus any files created by nspawn that way (and not chown()ed to
something better) will appear as unmapped (i.e. as overflowuid/"nobody")
in the container payload. And that's good. Of course, the latter is
mostly theoretic, as nspawn should generally chown() the inodes it
creates to UID ranges that actually make sense for the container (and we
generally already do this correctly), but it#s good to know that we are
safe here, given we might accidentally forget to chown() some inodes we
create.

Net effect: the two mappings will not be identical anymore. The mount
mapping has one entry more, and the only reason it exists is so that
nspawn can access the uidmapped fs reasonably independently from any
process mapping.

Fixes: #20989

base-filesystem: use uid_is_valid() at one more place

nspawn: if we refuse to operate on some directory, explain why

(Also, some refactoring to use safer path_join())

nspawn: make more stuff const

And if we make it const, we can also make it static.

nspawn: rebreak all comments in outer_child()

Changed wording in systemd-debug-generator manpage

core: add %d specifier for the $CREDENTIALS_DIRECTORY

Resolves: #22549

test: wait for loopback device being ready to manipulate

Follow-up for 6626ea08f6db3c050b5e05fa760cf0e371862173.

update TODO

core: drop an unnecessary initialization

udev: run the main process, workers, and spawned commands in /udev subcgroup

And enable cgroup delegation for udevd.
Then, processes invoked through ExecReload= are assigned .control
subcgroup, and they are not killed by cg_kill().

Fixes #16867 and #22686.

varlink_error_invalid_parameter(...) always returns EINVAL

varlink_error(...) expects a json object as the third parameter. Passing a string variant causes
parameter sanitization to fail, and it returns -EINVAL. Pass object variant instead.

repart: use assert() when no state is changed

core: ExecContext::restrict_filesystems is set of string

Merge pull request #22770 from yuwata/sd-radv-fixes

sd-radv: several fixes

timedate: use cleanup attribute at one more place

Revert "udev: do not kill "udevadm control" process in the same cgroup"

This reverts commit ccadf9ac0d6d206767294b3f96f41eb42b48d1b0.

The fix is not insufficient. See #22686.

sd-radv: fix indentation

sd-radv: do not use iterater outside of the loop

sd-radv: voidify sd_radv_remove_prefix()

If the prefix is only referenced by sd_radv, then the returned pointer
is already freed.

networkd does not uses the returned value. Let's voidify the function.

tpm2: enable parameter encryption

Use a salted, unbound HMAC session with the primary key used as tpmKey,
which mean that the random salt will be encrypted with the primary
key while in transit. Decrypt/encrypt flags are set on the new session
with AES in CFB mode. There is no fallback to XOR mode.

This provides confidentiality and replay protection, both when sealing
and unsealing. There is no protection against man in the middle
attacks since we have no way to authenticate the TPM at the moment.
The exception is unsealing with PIN, as an attacker will be unable
to generate the proper HMAC digest.

Merge pull request #22768 from poettering/cgls-delegate-xattr

make "delegate" xattr also available for unpriv programs

Merge pull request #22761 from poettering/pcr-fix

sd-boot: change kernel cmdline PCR from 8 to 12

Merge pull request #22765 from medhefgo/test

test: Use TEST macros in more places

sd-boot: disable bitlocker reboot feature for now

Conceptually the feature is great and should exist, but in its current
form should be worked to be generic (i.e. not specific to
Windows/Bitlocker, but appliable to any boot entry), not be global (but
be a per-entry thing), not require a BootXXXX entry to exist, and not
check for the BitLocker signature (as TPMs are not just used for
BitLocker).

Since we want to get 251 released, mark it in the documentation, in NEWS
and in code as experimental and make clear it will be reworked in a
future release. Also, make it opt-in to make it less likely people come
to rely on it without reading up on it, and understanding that it will
likely change sooner or later.

Follow-up for: #22043
See: #22390

Merge pull request #22563 from grigorig/cryptenroll-tpm2-pin

sd-cryptenroll TPM2 PIN protected unlock

NEWS: add entry announcing PCR change

man: only document new PCR 12

sd-boot: measure kernel cmdline into PCR 12 rather than 8

Apparently Grub is measuring all kinds of garbage into PCR 8. Since people
apparently chainload sd-boot from grub, let's thus stay away from PCR 8,
and use PCR 12 instead for the kernel command line.

As discussed here: #22635

Fixes: #22635

boot: use UINT32 as type for PCR indexes

Thisis what the TPM2/UEFI headers use, and most of our EFI codebase.
Let's also use the same type here in cpio.[ch]

boot: drop const from EFI_PHYSICAL_ADDRESS parameter

It's not a pointer after all, but a numeric value. As such the const
applies to the value and not the target, but we genreally don#t do that
for value parameters. Hence drop the const.

cgroup: also set user.invocation_id in addition to trusted.invocation_id

Similar thinking as the preceeding commit.

(While we are at it, let's unify some code we use over and over again in
two helper functions)

docs: document the user.delegate xattr

cgroup: also indicate cgroup delegation state in user-accessible xattr

So far we set the "trusted.delegate" xattr on cgroups where delegation
is on. This duplicates this behaviour with the "user.delegate" xattr.
This has two benefits:

1. unprivileged clients can *read* the xattr. "systemd-cgls" can thus
   show delegated cgroups as such properly, even when invoked without
   privs

2. unprivileged systemd instances can set the xattr, i.e. when systemd
   --user delegates a cgroup to further payloads.

This weakens security a tiny bit, given that code that got a cgroup
delegated can manipulate the xattr, but I think that's OK, given they
have a higher trust level regarding cgroups anyway, if they got a
subtree delegated, and access controls on the cgroup itself are still
enforced. Moreover PID 1 as the cgroup manager only sets these xattrs,
never reads them — the xattr is primarily a way to tell payloads about
the delegation, and it's strictly this one way.

test-journal-syslog: Add some valid priority cases

test: Use C11 UTF-16 string literal

test: Use TEST macros in more places

cgroup-show: split out delegation xattr check into its own function

Just some refactoring.

update TODO

docs: s/straight-forward/straightforward/

Inspired by https://github.com/systemd/systemd/pull/20156#discussion_r810878846

Merge pull request #22746 from yuwata/home-cleanups

home: two cleanups

import: improve error message

As suggested: https://github.com/systemd/systemd/pull/20156#discussion_r810941489

Merge pull request #22757 from DaanDeMeyer/bpf-error

BPF error logging improvements

cryptenroll: add tests for TPM2 unlocking

Add tests for enrolling and unlocking. Various cases are tested:

- Default PCR 7 policy w/o PIN, good and bad cases (wrong PCR)
- PCR 7 + PIN policy, good and bad cases (wrong PCR, wrong PIN)
- Non-default PCR 0+7 policy w/o PIN, good and bad cases (wrong PCR 0)

v2: rename test, fix tss2 library installation, fix CI failures
v3: fix ppc64, load module

cryptsetup: add manual TPM2 PIN configuration

Handle the case where TPM2 metadata is not available and explicitly
provided in crypttab. This adds a new "tpm2-pin" option to crypttab
options for this purpose.

cryptenroll: add TPM2 PIN documentation

cryptsetup: add libcryptsetup TPM2 PIN support

This is unfinished: we don't have any way to actually query for PINs
interactively this way. It is similar to FIDO2 and PKCS#11 in this
regard.

Nonetheless, this code is capable of validating and dumping tokens, so
it is already useful as-is.

cryptsetup: add support for TPM2 pin

Extend cryptsetup for TPM2 pin entry, similar to FIDO2.

cryptenroll: add support for TPM2 pin

Add support for PIN enrollment with TPM2. A new "tpm2-pin" field is
introduced into metadata to signal that the policy needs to include a
PIN.

v2: fix tpm2_make_luks2_json in sd-repart

tpm2: support policies with PIN

Modify TPM2 authentication policy to optionally include an authValue, i.e.
a password/PIN. We use the "PIN" terminology since it's used by other
systems such as Windows, even though the PIN is not necessarily numeric.

The pin is hashed via SHA256 to allow for arbitrary length PINs.

v2: fix tpm2_seal in sd-repart
v3: applied review feedback