TPM2 marshalling will never increase the total size, only possibly decrease.
There is no need for checking for insufficient size if the buffer size
is set to the sizeof both objects to be marshalled.
Salt was added in v253. We are not checking whether it was actually found
(non-zero size), so when an old tpm+pin enrollment is opened things go boom.
For good measure, check both the buffer and the size in both places.
Assertion 'saltlen > 0' failed at src/shared/tpm2-util.c:2490, function tpm2_util_pbkdf2_hmac_sha256(). Aborting.
At almost all places if diskseq is not supported we encode this as
diskseq zero. But in two places we got the check for that wrong,
assuming it was UINT64_MAX.
Fix that.
When displaying log data we deal with two kind of timestamps: the one we
use for display (typically the source timestamp if available), and the
one we use internally (typically the reception timestamp of journald).
The user-facing output modes generally use the display timestamp, the
ones intended for further processing (i.e. json + export outputs) do
not, and directly query the timestamps of the entry, ignoring the
source. This gets a bit confusing, since it's not always clear why we
use which timestamp where. Let's address that by renaming the generic
"ts" parameter/variable to "display_ts" to emphasize that the stored
timestamp are "corrected" timestamps for display only.
No real code change, just some renaming.
The kernel was updated to not use fake flex arrays with zero size.
Updating should allow -fstrict-flex-arrays to be used.
Headers pulled from kernel-headers-6.2.0-0.rc6.git0.1.fc38.x86_64.
Note that this is not a straighforward copy: our files have local modifications
(listed in README) that need to be preserved.
This will be used by Tpm2Handle instances, which is added in later patches.
The refcounting allows the context to be retained until all Tpm2Handles have
been cleaned up, and the initial ref is released, before cleaning the context.
The 'pcr_bank' functions operate on hash algs, and are not specific to the PCR
banks, while the 'primary_alg' functions operate on asymmetric algs, and are
not specific to primary keys.
If any query makes it to the end of install_info_follow() then I think symlink_target is set to NULL.
If that is followed by -EXDEV from unit_file_load_or_readlink(), then that causes basename(NULL)
which segfaults pid 1.
This is triggered by eg. "systemctl status crond" in RHEL9 if
/etc/systemd/system/crond.service
-> /ram/etc/systemd/system/crond.service
-> /usr/lib/systemd/system/.crond.service.blah.blah
-> /usr/lib/systemd/system/crond.service
Also, rename get_battery_identifier() to siphash24_compress_device_sysattr().
This also makes any errors in sd_id128_get_machine() or id128_get_product()
ignored. For the machine ID, the failure should not be significant unless
the file stored in the discharge level is reused by another system, which
is quite unusual. For the product ID, if the firmware provides useless
ID (all zero or all 0xFF), then loading/storing the discharge rate
becomes completely broken, that should be avoided.
Note, now sysattrs are used instead of properties in uevent files, but
both provide the same information, hence no functionality should be
changed.
Before v252, HibernateDelaySec= specifies the maximum timespan that the
system in suspend state, and the system hibernate after the timespan.
However, after 96d662fa4c, the setting is
repurposed as the default interval to measure battery charge level and
estimate the battery discharging late. And if the system has enough
battery capacity, then the system will stay in suspend state and not
hibernate even if the time passed. See issue #25269.
To keep the backward compatibility, let's introduce another setting
SuspendEstimationSec= for controlling the interval to measure
battery charge level, and make HibernateDelaySec= work as of v251.
This also drops implementation details from the man page.
Fixes#25269.
When compiled without ENABLE_EFI, efi_stub_measured() was not defined, so
compilation would fail. But it's not enough to add a stub that returns
-EOPNOTSUPP. We call this function in various places and usually print the error
at warning or error level, so we'd print a confusing message. We also can't add
a stub that always returns 0, because then we'd print a message like "Kernel
stub did not measure", which would be confusing too. Adding special handling for
-EOPNOTSUPP in every caller is also unattractive. So instead efi_stub_measured()
is reworked to log the warning or error internally, and such logging is removed
from the callers, and a stub is added that logs a custom message.
Let's port one more over.
Note that this changes behaviour of file_in_same_dir() in some regards.
Specifically, a trailing slash of the input path will be treated
differently: previously we'd operate below that dir then, instead of the
parent. I think that makes little sense however, and I think the code
using this function doesn't expect that either.
Moroever, addresses some corner cases if the path is specified as "/" or
".", i.e. where e cannot extract a parent. These will now be treated as
error, which I think is much cleaner.
read_battery_capacity_percentage() was already logging, but with a slightly
different wording.
More could be done, I just touched the most noticable places. Especially
in debug messages, it is much more useful to be direct about what couldn't
be accessed or parsed, instead of providing "descriptive names" which are
not useful to the user at all, who then needs to read the code to figure out
what was the actual property name.
Dan Streetman
Daan De Meyer
Lennart Poettering
Luca Boccassi
Dmitry V. Levin
Yu Watanabe
Samuel Cabrero
Zbigniew Jędrzejewski-Szmek
Robin Humble
Jan Janssen