Store the actual timeout value found by the driver in watchdog_timeout since
this value is more accurate for calculating the next time for pinging the
device.
This basically reverts commit 61927b9f11 and
relies on the fact that watchdog_ping() will open and setup the watchdog for us
in case the device appears later on.
Also unlike what is said in comment
https://github.com/systemd/systemd/pull/17460#pullrequestreview-517434377, both
m->watchdog[] and m->overriden_watchdog[] are not supposed to store the actual
timeout used by the watchdog device but stores the value defined by the user.
If the HW timeout value is really needed by the manager then it's probably
better to read it via an helper defined in watchdog.c instead. However the HW
timeout value is currently only needed by the watchdog code itself mainly when
it calculates the time for the next ping.
This patch allows watchdog_ping() to be used unconditionally regardless of
whether watchdog_set_timeout() or watchdog_close() has been previously called
or not and in both cases watchdog_ping() does nothing.
shutdown.c has been updated to cope with this change.
Add new settings which can be used to control cpuset based cpu affinity
during the startup phase only.
Signed-off-by: Peter Morrow <pemorrow@linux.microsoft.com>
This also changes the logic when Priority= is not specified.
Previously, we request without FRA_PRIORITY attribute and kernel picks
the highest unused priority for the rule.
This makes networkd picks the highest unused priority and always request
FRA_PRIORITY attribute.
In sd_journal_enumerate_fields(), we check if we've already handled
a field by checking if we can find it in any of the already processed
journal files. We do this by calling
journal_file_find_field_object_with_hash(), which compares the size,
payload and hash of the given field against all fields in a journal file,
trying to find a match. However, since we now use per file hash functions,
hashes for the same fields will differ between different journal files,
meaning we'll never find an actual match.
To fix the issue(), let's use journal_file_find_field_object() when one
or more of the files we're comparing is using per file keyed hashes.
journal_file_find_field_object() only takes the field payload and size
as arguments and calculates the hash itself using the hash function from
the journal file we're searching in.
NET_DEV_FEAT_TX matches multiple features. In the next commit, all
features whose strings start with "tx-checksum-" will be added.
To make them take precedence over NET_DEV_FEAT_TX, it will be applied
only when each explicit feature is not applied.
Previously, if a unit file which contains n IPAddressAllow/Deny= lines,
then the computational order of parsing the file was O(n^3), as
ip_address_access_reduce(), whose order is O(n^2), is called for each line.
By replacing in_addr_prefix related functions, now the computational
order is O(n log n).
Fixes#20680.
The current detection code relies on /sys/firmware/dmi/entries/0-0/raw
to disambiguate Amazon EC2 virtualized from metal instances.
Unfortunately this file is root only. Thus on a c6g.metal instance
(aarch64), we observe something like this:
$ systemd-detect-virt
amazon
$ sudo systemd-detect-virt
none
Only the latter is correct.
The right long term fix is to extend the kernel to expose the SMBIOS BIOS
Characteristics properly via /sys/class/dmi, but until this happens (and
for backwards compatibility when it does), we need a plan B.
This change implements such a workaround by falling back to using the
instance type from DMI and looking at the ".metal" string present on
metal instances.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Let's log every time we use uninitialized PCRs when unsealing a secret
via TPM2. This indicates a firmware issue usually, and is something we
shouldn't just show when enrolling but also show every time we unseal,
so that the fact that the selected PCR policy is pretty much pointless
is repeatedly shown.
Previously, we hardcoded use of ECC as primary keys, since they are much
faster (i.e. saving multiple seconds) to do TPM2 operations with. Alas,
not all TPM2 chips appear to support ECC. Bummer.
Let's hence add a fallback logic: if we can't create an ECC primary key,
use an RSA key, and store that fact away.
AFIU the security guarantees should be roughly the same, it's just that
RSA primary keys is so much slower to work with than ECC.
The primary key algorithm is used is stored in the JSON header of LUKS
disks, in a new field. If the field is absent we assume to use ECC, to
provide full compatibility with old systemd versions.
The primary key algorithm is stored in a new field in the credentials
file format (in fact, a previously unused zero space is used), too.
Hopefully, this should ensure that TPM2 support will "just work" on more
systems.
Fixes: #20361