IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Let's recommend that config files and drop-ins in /usr use the range
0-49 and config files in /etc and /run use the range 50-99 so that
files in /run and /etc will generally always override files from
/usr.
Let's get rid of the confusing goto so that the flow is more
straightforward. Note that the behavior is slightly changed:
previously, ret_filtered would be an empty string even if
the original opts passed in is NULL, but after this commit
it returns NULL too. But this shouldn't matter, as all our
code handles NULL opts gracefully.
This file is a bit misnamed. What it actually implements is one specific
BPF LSM module, that restricts file systems. As such it really should be
named after that, and not primarily by the mechanism it uses for that.
With this our glue code is now named the same way as the actual bpf code
files in src/core/bpf/, thus things become a bit more symmetric.
This is particular relevant as we'll soon have another BPF LSM in our
tree, see #26826, and we should be able to distinguish them by name.
This commit just renames the files and does some dumb search/replace of
the string. A follow-up commit will name some functions more expressively
inside the files.
I added the filtering in 752fedbea7 as a way
to reduce the number of items in the tables. I thought it's "obvious", but
it might not be so.
One immediate problem is that the filter is broken, because on arm64,
os.uname().machine returns "aarch64", so we incorrectly filter out the arm
syscalls (there is just one: arm_fadvise64_64). Of course we could fix the
filter, but I think it's better to nuke it altogether. The filter on applies to
1 arm syscall and 5 s390 syscalls, and we have 500+ other syscalls, so this
"optimization" doesn't really matter. OTOH, if we get the filter wrong,
the result is bad. And also, the existence of the filter at all creates
problems for cross-builds.
I wanted to get rid of 'generate-syscall-list.py', but we need to generate a
backslash in the output. https://github.com/mesonbuild/meson/issues/1564 makes
this very very hard, since any attempt to put a backslash an inline argument
results in the backslash being replaces by a forward slash, which doesn't quite
have the same meaning. So let's use a standalone script until
https://github.com/mesonbuild/meson/issues/1564 is resolved.
We can only delegate actual controllers, not the BPF pseudo-controllers
we defined as there's imply no concept for that. Hence, when users set
Delegate=yes to do a wildcard delegation, only delegate the regular
controllers.
This means that we won't bother with BPF stuff for such units where it's
entirelly unnecessary.
Currently, user_start() doesn't return any error,
but let's not eat up the return value.
Preparation for #30910, after which user_start()
does return error.
"Logging out" is something done by the human user. When we stop
tracking/GC a User object, let's use a more generic phrase in case
the specific User doesn't have human users (i.e. "user" class sessions)
at all. Eventually we want something like #2900, and log this
when all user class sessions log out and we're lingering again I think.
so that /usr/lib/systemd/tests/unit-tests/test-libsystemd-sym
builds in a reproducible way
in spite of non-deterministic filesystem readdir order
See https://reproducible-builds.org/ for why this is good.
This patch was done while working on reproducible builds for openSUSE.
If a nexthop is removed, dependent routes are silently removed by the kernel.
Hence, networkd may be confused that routes that depends on the nexthop still
exist, and may fail to configure other routes or so.
This is the one for routes of 3cbbe8635a.
If we could not remove a route, then previously the corresponding
Route object was never removed, as it was freed only when we receive
remove notification from the kernel. So, we might confused that the
route still exists and being removed, and might block reconfiguring
the route.
With this change, even if we fail to remove a route, the corresponding
Route object will be freed.
This is the one for routes of 56a995fe8e.
Then, replace route_remove_and_drop() with it.
If a route is requested, and the request is already called,
we may not received its reply and notification from the kernel, and
the corresponding Route object may not be remembered. Even in such
case, we need to remove the route, otherwise the route will come
later after the function called.
This is the version for route of f22b586a21.
In Knot 3.2 the nsec3-iterations default was changed to 0 and Knot now
issues a warning if the value is > 0. Let's just use the default value,
since it's not something that's important for our tests.
In confidential computing, a virtual firmware may support measurement and
event log based upon the hardware Trusted Execution Environment (TEE)
capability.
The UEFI specification defines an interface between the virtual guest OS
and virtual firmware as EFI_CC_MEASUREMENT_PROTOCOL. The (vendor specific)
measurements are captured in the CC eventlog that follows the TCG2 format.
OVMF virtual firmware has the EFI_CC_MEASUREMENT_PROTOCOL support for
Intel Trust Domain Extensions (TDX). Intel TDX has 4 runtime measurement
registers (RTMR) defined as:
RTMR[0] for TDVF configuration
RTMR[1] for the TD OS loader and kernel
RTMR[2] for the OS application
RTMR[3] reserved for special usage only
The RTMR to PCR mappings are defined in the UEFI Spec 2.10 Section 38.4.1
as follows:
TPM PCR Index | CC Measurement Register Index | TDX-measurement register
------------------------------------------------------------------------
0 | 0 | MRTD
1, 7 | 1 | RTMR[0]
2-6 | 2 | RTMR[1]
8-15 | 3 | RTMR[2]
The CC measurement eventlog is currently exposed as a raw CCEL ACPI table
by the guest OS and the events can be replayed to check log matches with
the RTMR values.
Add EFI CC measurement protocol to stub to get the UKI components measured
and included in the remote attestation reports when vTPMs are not available.
The documentation for `RestartPreventExitStatus=` differs from that for `SuccessExitStatus=` in ways that are sometimes confusing (e.g. using `numeric exit codes` instead of `numeric termination statuses`), and other times plain incorrect (e.g. not mentioning `termination status names`, which I've just confirmed to work in systemd 255).
This patch modifies the documentation to be as similar as possible, so as to reduce the reader's cognitive load.
Previously, a Route object is owned by a Link object corresponding to the
outgoing interface of the route, and a Route object that does not have
outgoing interface is owned by the Manager object.
However, there were several issues:
- if a route has a nexthop ID, then the corresponding nexthop may be
changed to use another interface, hence the outgoing interface of the
route may be changed.
- if a route requested with MultiPathRoute=, then the link who requests
the route is different from the outgoing interface of the configured
route. So, we need to find routes on other interfaces on reconfiguring
or so.
By this change, the limit of the number of routes per-interface is
tentatively dropped. Let's re-introduce the limit later in a nicer way.
