sysctl-util: make sysctl_read_ip_property() a wrapper around sysctl_read()
let's do what we did for sysctl_write()/sysctl_write_ip_property() also
for the read paths: i.e. make one a wrapper of the other, and add more
careful input validation.
sysctl-util: make sysctl_write_ip_property() a wrapper around sysctl_write()
It does the same stuff, let's use the same codepaths as much as we can.
And while we are at it, let's generate good error codes in case we are
called with unsupported parameters/let's validate stuff more that might
originate from user input.
sysctl-util: rework sysctl_write() to wrap write_string_file()
The sysctl_write_ip_property() call already uses write_string_file(), so
let's do so here, too, to make the codepaths more uniform.
While we are at it, let's also validate the passed path a bit, since we
shouldn't allow sysctls with /../ or such in the name. Hence simplify
the path first, and then check if it is normalized, and refuse if not.
fileio: lower maximum virtual file buffer size by one byte
When reading virtual files (i.e. procfs, sysfs, …) we currently put a
limit of 4M-1 on that. We have to pick something, and we have to read
these files in a single read() (since the kernel generally doesn't
support continuation read()s for them). 4M-1 is actually the maximum
size the kernel allows for reads from files in /proc/sys/, all larger
reads will result in an ENOMEM error (which is really weird, but the
kernel does what the kernel does). Hence 4M-1 sounds like a smart
choice.
However, we made one mistake here: in order to be able to detect EOFs
properly we actually read one byte more than we actually intend to
return: if that extra byte can be read, then we know the file is
actually larger than our limit and we can generate an EFBIG error from
that. However, if it cannot be read then we know EOF was hit, and we are
good. So ultimately after all we issued a single 4M read, which the
kernel then responds with ENOMEM to. And that means read_virtual_file()
actually doesn't work properly right now on /proc/sys/. Let's fix that.
The fix is simple, lower the limit of the the buffer we intend to return
by one, i.e. 4M-2. That way, the read() we'll issue is exactly as large
as the limit the kernel allows, and we still get safely detect EOF from
it.
Franck Bui [Wed, 4 Aug 2021 09:20:07 +0000 (11:20 +0200)]
journalctl: never fail at flushing when the flushed flag is set
Even if journald was not running, flushing the volatile journal used to work if
the journal was already flushed (ie the flushed flag
/run/systemd/journald/flushed was created).
However since commit 4f413af2a0a, this behavior changed and now '--flush' fails
because it tries to contact journald without checking the presence of the
flushed flag anymore.
This patch restores the previous behavior since there's no reason to fail when
journalctl can figure out that the flush is not necessary.
watchdog: update watchdog_timeout with the closest timeout found by the driver
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 61927b9f116bf45bfdbf19dc2981d4a4f527ae5f 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.
watchdog: make watchdog_ping() a NOP when the watchdog is disabled or closed
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.
Yu Watanabe [Tue, 31 Aug 2021 08:24:07 +0000 (17:24 +0900)]
network: use NetworkConfigSource/State to manage routing policy rules
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.
sd-journal: Don't compare hashes from different journal files
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.
ethtool-util: apply tx-checksum-* features at last
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.
This is an effort to compile a somewhat complete list how PCRs are
actually used on Linux systems these days. It contains data from: the
UEFI PC spec, the shim, the IMA, grub documentation.
I validated these PCRs to some level in the sources.
The grub specific stuff I only added in comments, since I was too lazy
too validate it (also, meh, grub).
It also gives people a hint on which PCR to bind to (and maybe kind of
an explanation of our default choice).
core: replace IPAddressAccessItem with struct in_addr_prefix
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).
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.
tpm2: support RSA primary keys as fallback if TPM2 devices don't support ECC
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.
cryptenroll allows to specify a custom TPM driver separated from
parameters with colon e.g. `systemd-cryptenroll --tpm2-device=swtpm:`
tells to load swtpm tss driver and use it as a device.
Unfortunately it does not work, swtpm driver init() fails with
```
debug:tcti:src/tss2-tcti/tcti-swtpm.c:570:Tss2_Tcti_Swtpm_Init() Dup'd conf string to: 0x562f91cbc000
debug:tcti:src/util/key-value-parse.c:85:parse_key_value_string() parsing key/value: swtpm:
WARNING:tcti:src/util/key-value-parse.c:50:parse_key_value() key / value string is invalid
Failed to initialize TCTI context: tcti:A parameter has a bad value
```
It turns out that cryptenroll suppose to use the driver name internally
and strip it before passing the rest of parameters to init() function.
Without doing it swtpm receives incorrect key-value property and gets
confused.
Fix it by passing the correct parameter (without driver name) to the
init() function.
network: always call address ready callback if address is ready
The address ready callback is used for cleaning up old addresses or
routes acquired by e.g. DHCP. However, the callback was called only
when the address was previously not ready. So, maybe, unnecessary
addresses or routes may not be cleared.
Also, this makes the callback is called slightly earlier. As it may
remove several addresses or routes, and possibly changes the link state.
projects / thirdparty / systemd.git / log
