When a node of traffic control tree is removed, all child nodes are also
removed but their removal are not notified by the kernel.
So, previously, removed TC classes or qdiscs under the removed node were
kept in the memory of networkd, and may cause failure on reconfigure.
Currently only an auto-reboot-to-firmware entry is available. For other
features - like reboot and power off - one needs to press the uppercase
B and O respectively.
Embedded devices may be missing a full fledged keyboard, so allow for
sd-boot to generate those entries.
v2:
- add to the config parser/man/bootctl/sd-boot info screen
- keep them off by default
- add the (O)ff and re(B)oot help text if boot entries are not shown
- drop irrelevant get_os_indications_supported() comment
- s/ShutDown/Shutdown/
v3:
- cast shutdown_system() reboot_system() to void
v4:
- shutdown -> poweroff
- add trailing ",ignoring" in parser message
- drop explicit default state assignment to "false"
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
As mentioned by Lennart:
... we typically suffix such messages with ", ignoring", to indicate
that we don't consider this fatal for anything.
Update config_defaults_load_from_file() to follow that pattern.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
When the assignment is missing, the default 0/NULL/false value is used.
So drop the explicit piece in config_load_defaults()
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
As mentioned by Lennart, in a commit where I was adding similar piece of
code:
maybe cast this call to void, to tell static analyzers that we are
ignoring the return value on purpose, not by accident
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
The naming was confused: suffix 'p' means that the function takes a pointer to
the type that the wrapped function takes. (E.g., a char**, for a wrapped function
taking a char*.) But DEFINE_TRIVIAL_DESTRUCTOR() just changes the return type.
Also add one more assert for consistency.
This is primarily supposed to be a 1st step with varlinkifying our
various command line tools, and excercise in how this might look like
across our codebase one day. However, at AllSystemsGo! 2023 it was
requested that we provide an API to do a PCR measurement along with a
matching event log record, and this provides that.
This call checks if we are invoked in a socket-activation Varlink server
context. It's useful for commands that can be run from the command line
or as Varlink service and then either serve commands from the cmdline or
those from Varlink.
This is a helper call that runs the specified VarlinkServer object in an
event loop, and exits once no more connections exist.
This is useful for pure varlink servers (i.e. those which only server
varlink requests and do nothing else), to run as long as there's
something to do and exit right after.
This new helper will automatically take listening fds passed in from the
service manager and processes varlink on them. It's useful for Varlink
services that shall be socket activatable.
This adds a logic that if enabled ensures sd_event_exit() is called
whenever the varlink connection count hits zero.
This is useful for implementing pure Varlink services (i.e. services
whose only job is to serve Varlink requests), that shall run only as
long as needed, i.e. as long as at least one request is being served.
This error is a private error returned by PID 1 to oomd. It's internal,
and very specific to the use-case. Hence it should not be part of the
org.varlink.service interface (which isn't really our namespace anyway).
Hence, let's clean this up and move it over to the ManagedOOM varlink
interface of PID, where it belongs.
Since this is a private protocol of our two daemons, and the client
(i.e. oomd) doesn't explicitly test for this error anyway we can just
move it over without ill effects.
The official org.varlink.service interface definition, as per:
https://varlink.org/Service
And the io.systemd service where we carry some super generic errors our
Varlink implementation generates.
Let's mention that we just need the latest stable release of mkosi,
not the latest git commit. We also split the instructions for building
on the host and the instructions for building with mkosi into two blocks,
as it's not required to build on the host anymore to build with mkosi.
When verifying seals produced with forward secure sealing, the verification
currently does not check that old entries are only sealed with the key for
their epoch and not a more recent one. This missing check allows an attacker
to remove seals, and create new ones with the currently available key, and
verify will claim everything is in order, although all entries could have
been modified.
This resolves CVE-2023-31439.
Co-authored-by: Felix Dörre <felix.doerre@kit.edu>
Previously, if the input offset 'p' does not point to an entry object,
the function returns the next of the nearest entry object on
DIRECTION_DOWN, as generic_array_bisect() already returns the nearest
entry object.
Yu Watanabe
Daan De Meyer
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Emil Velikov
Lennart Poettering
G2-Games
felixdoerreandFelix Dörre