We were passing the dir handle for the ESP to
config_entry_bump_counters(), which will obviously fail if the entry
actually resides on the XBOOTLDR partition.
Fixes: #28637
$ journalctl -u systemd-bless-boot.service
systemd[1]: Starting Mark the Current Boot Loader Entry as Good...
systemd-bless-boot[536]: Marked boot as 'good'. (Boot attempt counter is at 2.)
systemd-bless-boot[536]: Can't find boot counter source file for '/loader/entries/arch.conf': Device or resource busy
systemd[1]: Finished Mark the Current Boot Loader Entry as Good.
We were running systemd-measure before adding the sbat section,
let's fix that.
Also make sure we only pass --linux to systemd-measure once instead
of twice.
Previously, we first generate names based on the PCI slot and ACPI
onboard index, and then append an identifier based on USB or BCMA bus
if it exists in between the PCI bus and the interface.
However, if there exists USB or BCMA bus, the name based on the
ACPI onboard index is not used.
So, let's invert the order; first generate USB or BCMA identifier if the
bus exists, then prepend the name with the PCI slot identifier.
With this change, we can drop Names struct, and each naming logic
becomes self-consistent.
Then call it only when it is necessary. The label is used only when the
interface is directly connected to the PCI bus, and it does not have the
SR-IOV feature (or the naming based on SR-IOV is disabled).
This contains redundant copy of BCMA identifier, but that will be
dropped in the next commit.
No functional change, just refactoring and preparation for later
commits.
This contains redundant copy of USB identifier, but that will be
dropped in the next commit.
No functional change, just refactoring and preparation for later
commits.
manager_{get|set|override}_watchdog check the validity of the new
timeout or the overridden timeout values using timestamp_is_set which
does not recognize "0" as a valid value. However since f16890f, "0"
indicates a disabled watchdog and so is a value we should be able to
configure in order to disable the watchdog. A value of USEC_INFINITY is
considered a no-op. The behavior should be the same for all watchdog
timeout configurations (runtime, pretimeout, and shutdown).
Private mappings are required when F_SEAL_WRITE is set on a memfd,
because otherwise you could end up with writable mappings through
mprotect() and other calls. This is a limitation of the kernel
implementation, and might be lifted by future extensions.
Regardless, the current code tests for the full `is_sealed()` before
using MAP_PRIVATE. This might end up using MAP_SHARED for write-sealed
memfds, which will be refused by the kernel.
Fix this and make memfd_map() check for exactly `F_SEAL_WRITE`.
Rather than always setting all seals, make `memfd_set_seals()` employ
the original set of seals, that is: SEAL+GROW+SHRINK+WRITE
Historically, the memfd code was used with the out-of-tree memfd
patches, which merely supported a single seal ("SEALED", which
effectively was GROW+SHRINK+WRITE). When the code was adapted to the
upstream memfd seals, it was extended to the full seal set. With more
and more seals being added upstream, this because more problematic. In
particular, it is unclear what the function really is meant to achieve.
Instead of just adding all seals, the function is returned to its
original purpose: seal the memfd so futher modifications to its content
are prevented.
With `F_SEAL_SEAL` a memfd can disable further sealing operations,
effectively sealing the set of seals. Testing for it ensures that no
further seals can be added, it never prevents seals from being dropped,
since seals cannot be dropped, ever.
Now testing for `F_SEAL_SEAL` makes sense if you want to ensure that
some seals are *not* set. That is, you either test for the entire set of
seals to match a local set, or you verify that a specific seal is not
set. Neither is what we are doing, so it feels wrong requiring it to be
set.
By dropping the requirement for `F_SEAL_SEAL`, the same FD can be shared
with other entities while retaining the ability to further restrict the
set of seals later on (e.g., being able to mark a region as executable
later on, and then adding `F_SEAL_EXEC`).
