Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v254 batch #416

Merged
merged 15 commits into from
Jun 25, 2024
Merged

v254 batch #416

merged 15 commits into from
Jun 25, 2024

Conversation

bluca
Copy link
Member

@bluca bluca commented Jun 25, 2024

No description provided.

yuwata and others added 15 commits June 25, 2024 12:18
I do not think this is necessary, but all other places in
libsystemd-network we clear buffer before receive. Without this,
Coverity warns about use-of-uninitialized-values.
Let's silence Coverity.

Closes CID#1469721.

(cherry picked from commit 40f9fa0)
(cherry picked from commit 0d573787ea1610ba57a359cf437841f62b186e77)
(cherry picked from commit aa93c07)
As per the suggestion in systemd/systemd#33242.

This reduces the number of /dev/ttySXX device units generated in
mkosi from 32 to 4.

(cherry picked from commit dc38f9a)
(cherry picked from commit a3d94332a2b5128697373d3093c1cfa56649ec61)
(cherry picked from commit 6391242)
This allows us to reserve a bunch of capacity ahead of time,
improving the performance of hwdb significantly thanks to not
having to reallocate so many times.

Before:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==113297== Memcheck, a memory error detector
==113297== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==113297== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==113297== Command: ./systemd-hwdb update
==113297==
==113297==
==113297== HEAP SUMMARY:
==113297==     in use at exit: 0 bytes in 0 blocks
==113297==   total heap usage: 1,412,640 allocs, 1,412,640 frees, 117,920,009,195 bytes allocated
==113297==
==113297== All heap blocks were freed -- no leaks are possible
==113297==
==113297== For lists of detected and suppressed errors, rerun with: -s
==113297== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
132.44user 21.15system 2:35.61elapsed 98%CPU (0avgtext+0avgdata 228560maxresident)k
0inputs+25296outputs (0major+6886930minor)pagefaults 0swaps
```

After:
```
$ sudo time valgrind --leak-check=full ./systemd-hwdb update
==112572== Memcheck, a memory error detector
==112572== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==112572== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==112572== Command: ./systemd-hwdb update
==112572==
==112572==
==112572== HEAP SUMMARY:
==112572==     in use at exit: 0 bytes in 0 blocks
==112572==   total heap usage: 1,320,113 allocs, 1,320,113 frees, 70,614,501 bytes allocated
==112572==
==112572== All heap blocks were freed -- no leaks are possible
==112572==
==112572== For lists of detected and suppressed errors, rerun with: -s
==112572== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
21.94user 0.19system 0:22.23elapsed 99%CPU (0avgtext+0avgdata 229876maxresident)k
0inputs+25264outputs (0major+57275minor)pagefaults 0swaps
```

Co-authored-by: Yu Watanabe <[email protected]>
(cherry picked from commit 621b10f)
(cherry picked from commit 514ef0f93b76cbe0ba6b4de07a7b21fd0c2b7bae)
(cherry picked from commit aa0dd89)
This check introduced in 91adc4d is intended to spare us from
encountering broken resolver behavior we don't want to deal with.
However if we aren't validating we more than likely don't know the state
of the upstream resolver's support for dnssec. Let's let clients try
these queries if they want.

This brings the behavior of sd-resolved in-line with previouly stated
change in the meaning of DNSSEC=no, which now means "don't validate"
rather than "don't validate, because the upstream resolver is declared to
be dnssec-unaware".

Fixes: 9c47b33 ("resolved: enable DNS proxy mode if client wants DNSSEC")
(cherry picked from commit 364c948)
(cherry picked from commit ba031f1fe86e36d7adc0340b047de32399c98bf7)
(cherry picked from commit 5299397)
Let's skip udev device scanning when activating a LUKS volume in
systemd-repart as we don't depend on any udev symlinks and don't
expect anything except repart to access the volume.

Suggested by systemd/systemd#33129 (comment).

(cherry picked from commit 726fc7a)
(cherry picked from commit d316aed5d8e15fb5b13b5618f1b2d1d020b1e7bf)
(cherry picked from commit 1ccc38e)
SHA384 is pretty much the bank we actually *want* to use, since it's
faster to calculate than SHA256, hence at the very least, start
considering.

(cherry picked from commit acaca5ab250a51be6ba07768bee80bf0f7b462fa)
(cherry picked from commit 51390a1f41a762ef96d3c496d8a5d890d722907d)
(cherry picked from commit 5024b1b)
Historically, systemd-tmpfiles was designed to manager temporary
files, but nowadays it has become a generic tool for managing
all kinds of files. To avoid user confusion, let's remove "temporary"
from the tool's description.

As discussed in #33349

(cherry picked from commit b5c8cc0a3b8e4e2fea0539d6420a76b524ea5735)
(cherry picked from commit 1a0e6961cfaed42bda542e111738c136f7b4d73f)
(cherry picked from commit c752efd)
Follow-up for 45b1017

(cherry picked from commit 9f5d8c3da4f505346bd1edfae907a2abcdbdc578)
(cherry picked from commit f7d55cc801611781fbff2817f2fd4a16ec96ca85)
(cherry picked from commit 8ead254)
If a symlink is leftover, still allow cleaning it up via 'disable'. This
happens when a unit is stopped and removed, but not disabled, and a reload
has already happened. At that point, cleaning up the old symlinks becomes
impossible through the APIs, and needs to be done manually. Always allow
cleaning up symlinks, if they exist, by only erroring out if there is an
OOM.

Follow-up for f31f10a

(cherry picked from commit 5163c9b1e56293b1bb2803420613c5b374570892)
(cherry picked from commit c26e56d08f30a2946dfa1d03781c63bfa9f56c1d)
(cherry picked from commit 44c08e6)
(cherry picked from commit a81f5ffd40081441dafc678fe83d185436dde35a)
(cherry picked from commit f8f669fd69bf15f386308ef8f4cbbbd5a7ad69cd)
(cherry picked from commit 759ddfd)
If the ceck for the ACPI TPM2 table did not work we currently check if
the EFI TPM table exists to check if the firmware supports TPM2.
Specifically we check if
/sys/kernel/security/tpm0/binary_bios_measurements exists. But that's
not enough, since that also exists on TPM1.2 systems. Hence, let's also
check /sys/class/tpm/tpm0/tpm_version_major which should exist under
similar conditions and tells us the kernel's idea of the TPM version in
use.

I originally intended to read the signature of the
/sys/kernel/security/tpm0/binary_bios_measurements contents for this,
but this is not ideal since that file has tight access mode, and our TPM
availability check would thus not work anymore if invoked unpriv.

Follow-up for 4b33911

Fixes: #33077
(cherry picked from commit aeaac9a)
(cherry picked from commit b2046c3)
While tracing a LUKS code path in homework, I've noticed that we don't
erase buffers when doing unbase64 or unhex on JSON variants, even if the
variant is marked as sensitive.

(cherry picked from commit 80313c5)
(cherry picked from commit cce7df4)
Follow-up for 28459ba

The pty path returned by OpenMachinePTY() cannot be opened from outside
the machine, hence let's use the plain Standard{Input,Output,Error}=tty
in such a case. This means if --machine= is specified, #32916 would occur.
A comprehensive fix requires a new dbus method in machined, which shall
be material for v257.

See also: systemd/systemd#33216 (comment)

Replaces #33216

Co-authored-by: Mike Yuan <[email protected]>
(cherry picked from commit ddef3ec)
(cherry picked from commit 639c922)
Currently the check also succeeds if the input path starts with a dot, whereas
we only want it to succeed for "." and "./". Tighten the check and add a test.

(cherry picked from commit 7efaab4)
(cherry picked from commit 81f6faf)
@bluca bluca merged commit 1b12eca into systemd:v254-stable Jun 25, 2024
39 of 43 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

10 participants