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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
These aren't wired up yet to do anything useful. For now we just define
them.
This sections are supposed to carry a signature for expected
measurements on PCR 11 if this kernel is booted, in the JSON format
"systemd-measure sign" generates, and the public key used for the
signature.
The idea is to embedd the signature and the public key in unified
kernels and making them available to userspace, so that userspace can
easily access them and enroll (for which the public key is needed) or
unlock (for which the PCR signature is needed) LUKS2 volumes and
credentials that are bound to the currently used kernel version stream.
Why put these files in PE sections rather than just into simple files in
the initrd or into the host fs?
The signature cannot be in the initrd, since it is after all covering
the initrd, and thus the initrd as input for the calculation cannot
carry the result of the calculation. Putting the signature onto the root
fs sucks too, since we typically want to unlock the root fs with it,
hence it would be inaccessible for it's primary purpose then.
The public key could be in the initrd or in the root fs, there's no
technical restriction for that. However, I still think it's a good idea
to put it in a PE section as well, because this means the piece of code
that attaches the signature can also attach the public key easily in one
step, which is nice since it allows separating the roles of the
kernel/initrd/root fs builder, and the role of the signer, and the
former doesn't have to have knowledge about what the latter is going to
add to the image.
Note that the signature section is excluded from the TPM measurements
sd-stub does about its resource sections, since – as mentioned – it's
the expected output of the signing operation whose input are the
measurements, hence it cannot also be input to them. The public key
section is included in the measurements however.
Report whether the devicetree + sort-key boot loader spec type #1
fields are supported, and whether the "@saved" pseudo-entry is
supported.
Strictly speaking, thes features have been added in versions that are
already released (250+), so by adding this those version even though
they support the features will be considered not supporting them, but
that should be OK (the opposite would be a problem though, i.e. if we'd
assume a boot loader had a feature it actually does not).
These three features are features relevant to userspace, as it allows
userspace to tweak/genereate BLS entries or set EFI vars correctly.
Other features (i.e. that have no impliciations to userspace) are not
reported.
systemd-boot reports its features via the LoaderFeatures EFI variable.
Let's add something similar for stub features, given they have been
growing.
For starters only define four feature flags. One is a baseline feature
we pretty much always supported (see comment in code), two are features
added in one of the most recently released systemd version, and the
final one, is a feature we added a few commits ago.
This is useful for userspace to figure out what is supported and what
not.
Objects without ObjectManager should not have
`org.freedesktop.DBus.ObjectManager` interface.
Object with ObjectManager should do.
Also added ASSERT_SE_NONNEG and ASSERT_NONNEG macros.
NetworkManager takes systemd sources. It gets compiler warnings
related to _fallthrough_. They probably can also affect systemd
itself.
A) on RHEL-7, gcc 4.8.5-44.el7 we get:
../src/libnm-systemd-shared/src/fundamental/macro-fundamental.h:45:22: error: "__clang__" is not defined [-Werror=undef]
#if __GNUC__ >= 7 || __clang__
^
Presumably gcc older than 7 is supported, so fix this.
B) on Ubuntu 18.04, clang 1:6.0-41~exp5~ubuntu1 we get:
../src/libnm-systemd-core/src/libsystemd-network/sd-dhcp6-client.c:746:17: error: declaration does not declare anything [-Werror,-Wmissing-declarations]
_fallthrough_;
^
../src/libnm-systemd-shared/src/fundamental/macro-fundamental.h:46:25: note: expanded from macro '_fallthrough_'
# define _fallthrough_ __attribute__((__fallthrough__))
^
Granted, README comments that clang >= 10 is required. However,
parts of systemd build just fine with older clang. It seems unnecessary
to break this and the fix helps NetworkManager.
Fixes: c0f5d58c9ab7 ('meson: Document why -Wimplicit-fallthrough is not used with clang')
We now have a local implementation in string-util-fundamental.c, but
it's useful at a lot of other places, hence let's give it a more
expressive name and share it across the tree.
Follow-up for: 8d9156660d6958c8d63b1d44692968f1b5d33920
This removes the fundamental typedefs in favor of just using standard C
types. These are all used internally anyway and also do not do anything
special to warrant any redefinition to EFI types.
Even for BOOLEAN we can safely use stdbool. The defition from the EFI
specification is fully compatible, including making any other values
than 0/1 as undefined.
The exception is sd_char as those need to be char16_t. The typedef is
moved to string-util-fundamental.h instead.
The casts in this and the next few commits are curently necessary
because CHAR8 is defined as uint8_t in gnu-efi, while char is signed.
Once we switch from gnu-efi typedefs to stdint types, the casts
will be dropped.
So far we had the rule that '' == '', '0_' == '0', but '_' > ''. This means
that the general rule that strings are compared iteratively, and each
segment that compares equal can be dropped and the comparison resumes at
the following characters wasn't true in such cases. Similarly, '0~' < '0',
but after dropping the common segment, '~' > ''.
The special handling of empty strings is dropped, and '_' == '' and
'~' < ''.
The docs are not entirely clear what glyphs qualify as digits.
The function is supposed to be locale-dependent, but I couldn't
get it to return true on any non-ascii digits I tried.
But it's better to be safe than sorry, let's use our trivial
replacement instead.
The SBAT section was included in a special section in the EFI code, but
the contents weren't directly visible in any way. Let's add a "test" that
prints them for visual inspection.
If there's some external linter for this format, we could hook it up in the
future.
We would return the result of strcmp(), i.e. some positive/negative value.
Now that we want to make this a documented interface for other people
to implement, let's make the implementation more contstrained, even if
we ourselves don't care about whether the specific values.
ASSERT_SE_PTR() is like ASSERT_PTR() but uses assert_se() instead of
assert() internally.
Code should use ASSERT_SE_PTR() where the check should never be
optimized away, even if NDEBUG is set.
Rationale: assert() is the right choice for validating assumptions about
our own code, i.e. checking conditions that are "impossible" to not
hold, because we ourselves hacked things up the "right" way of course.
assert_se() is the right choice for tests that come with a weaker
guarantee, they encode assumptions over other's API behaviour, i.e.
whether something can fail there or not.
When developing tools that are not oom-safe assert_se() is the right
choice: we know that on Linux OOM doesn't really happen, even though
theoretically the API allows it to happen.
Usecase for ASSERT_SE_PTR() is mostly the fatal memory allocation logic
for EFI memory allocations. So far it used regular assert() i.e. OOM
failurs would be totally ignored if NDEBUG is set. We'd rather have our
EFI program to print an assert message and freeze instead though.
We'd connect to the bus twice: the first time to check networkd namespace,
and then the second time to do the deed we were asked to do. It's nicer
to open the bus just once, for efficience and also to avoid the open call
in all functions.
An ASSERT_PTR helper is added:
- sd_bus *bus = userdata;
...
- assert(bus);
+ sd_bus *bus = ASSERT_PTR(userdata);
...
It can be used in other place too, but I'm leaving that for a later
refactoring.
