The package notes are nice standard mechanism to figure out the exact name and
version of a program or a library stored in a file, without running the code.
In the beginning this was designed for the purpose of analyzing core dumps, but
we've since started to use it more generically to identify files. The same need
to identify PE/COFF files occurs, for example for systemd-boot and other files
intended for UEFI. It has also been requested by people working on bootupd
(https://github.com/coreos/bootupd).
The text is changed to say "Executable" or "ELF or PE/COFF" wherever "ELF" was
used previously.
The description for PE/COFF files is very brief. AFAIK, we don't have the same
"note" mechanism there [1], so just a normal section is used. The alignment
rules for PE/UEFI are different and change over time, so no specific alignment
is specified.
Other requirements for the PE/COFF section are based on what ukify currently
does for the .osrel section:
5 .osrel 00000056 000000010132f000 000000010132f000 0002b600 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
The name ".pkgnote" is used as suggested by Daan De Meyer. This corresponds to
the ".note.package" name used for ELF. ".package" was also suggested, but I
think that is too generic and carries more risk of a conflict with a different
use.
[1] https://learn.microsoft.com/en-us/windows/win32/debug/pe-format
Also zero/0 is replaced by NUL to clarify that a single 0 byte is meant.
We described the "how", but not the "why". And the text was a bit dated,
still mostly talking about core files. Let's make it more general
and describe why a section is used.
Add a recommendation/explanation for the debugInfoUrl field.
This document is renamed without any changes in a separate commit.
Otherwise, git does not show a diff, which makes it very hard
to review what is actually changed in the text.
RestrictNamespaces= would accept "time" but would not actually apply
seccomp filters e.g. systemd-run -p RestrictNamespaces=time unshare -T true
should fail but it succeeded.
This commit actually enables time namespace seccomp filtering.
Previously if one service specified the same unit as their
success and failure handler we bailed out of resolving the triggering unit
even though it is still unique.
These new tests are flaky, so disable them temporarily, until after
the release, to avoid pushing out new flakiness to consumers. They
will be re-enabled immediately after.
Instead of the wrapper functions the color defines where used directly.
This was especially a problem for ANSI_HIGHLIGHT_YELLOW which is not
legible at all for light themes such as solarized. The 16 color palette
fallback can be set to a sane yellow or orange on that matter but it was
not used though `SYSTEMD_COLORS=16` was set.
Use the proper wrapper functions and let the right color be selected the
way other components do it already.
We'd silently skip devices which don't have the feature in the list.
This looked wrong esp. if no devices were suitable. Instead, list them
and show which ones are usable.
$ build/systemd-cryptenroll --fido2-device=list
PATH MANUFACTURER PRODUCT HMAC SECRET
/dev/hidraw7 Yubico YubiKey OTP+FIDO+CCID ✓
/dev/hidraw10 Yubico Security Key by Yubico ✗
/dev/hidraw5 Yubico Security Key by Yubico ✗
/dev/hidraw9 Yubico Yubikey 4 OTP+U2F+CCID ✗
The values that were previously hardcoded in sd-varlink.c are now defined
in new varlink_set_info_systemd() and that function is called everywhere
where we create a server.
Fixes https://github.com/systemd/systemd/issues/35508.
As reported in the bug, the values were hardcoded for the systemd project.
https://varlink.org/Service lists vendor, product, version, url, and interfaces
as the mandatory parameters, so add an interface to set the first four. The
last field is set automatically based on the registered interfaces as before.
If the values are not filled in, we return empty strings. With NULL,
'varlinkctl info' would say:
(string):1:25: Object field 'vendor' has wrong type null, expected string.
Otherwise, if networkd is failed, e.g. .network files that triggered the
failure will remain, and the next test case will start with previous
.network files. So, most subsequent test will fail.
This adds the following three options:
- detect_invalid_pointer_pairs=2
- handle_ioctl=1
- print_cmdline=1
Note, these options were used in the CentOS CI job.
To build rawhide images we might need more recent tools from rawhide
itself. While Arch would generally be up-to-date enough as well, it
doesn't provide the selinux tools so we use Fedora Rawhide instead.
This is a revised version of cbd5f5d7d6,
which is reverted by 560412148f.
The filter condition for _UID= field was added by
fdcd37df3b. However, after
888e378da2, coredumps for system services are
stored by systemd-coredump user. Hence, _UID=0 does not match anything anymore.
When we are reading the system journal, let's set _UID=<systemd-coredump>,
then we can show coredumps for system services again. When we are reading
an external journal, then the uid of systemd-coredump may be different
from the one on the current system, so let's drop the filter condition
for _UID= in that case.
This is a follow-up for f8fa4222c9 (boot: Make
initrd_prepare() semantically equivalent to combine_initrds()). That commit
changed the way that the initrd is prepared for type#1 boot loader entries,
also effectively rounding up the sizes to a multiple of 4. In [1], downstream
packagers report that the trailing zeroes result in the calculated hash being
different. To restore compatibility with previous hash calculations and
signatures, change the reported size by excluding the trailing padding. This
should restore the calculation results for the case where only one initrd is
used.
This patch doesn't touch the stub, i.e. doesn't change behaviour for UKIs. The
seems fine, since we didn't change that recently, so any changes there would
break compatiblity. The measurement results for type#1 and type#2 entries are
generally going to be different anyway. ukify and systemd-measure are also out
of scope here, because they are for UKIs.
Fixes https://github.com/systemd/systemd/issues/35439.
The other changes to the way the initrd is constructed are kept, so hopefully
the original issue with booting in qemu is not recreated.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1233752
My simple test: I'm booting a QEMU VM with systemd-boot and a type#1 entry.
With old systemd-boot:
$ sudo systemd-pcrlock log | grep 'kernel-initrd.*event-tag'
9 █ kernel-initrd event-tag - a337a8321bf81de5c53a842843e8f9a926f73a676e5620ff76df94d1c66bc931 F - Linux: kernel command line
9 █ kernel-initrd event-tag - aec1aee5358bde36f5498f2dc243dec2b103f81242de57b887a11f53677f1272 F - Linux: initrd
With updated systemd-boot:
$ sudo systemd-pcrlock log | grep 'kernel-initrd.*event-tag'
9 █ kernel-initrd event-tag - a337a8321bf81de5c53a842843e8f9a926f73a676e5620ff76df94d1c66bc931 F - Linux: kernel command line
9 █ kernel-initrd event-tag - 3ccaa710304aef8734a20265ea7fd3dd67d5461c6b3309c6d30d5c7d2a3ae7f9 F - Linux: initrd
This matches the initrd hash:
$ sudo sha256sum /efi//26f948d2082e4ae89f5a3af351b63149/6.12.0-rc4+/initrd-dracut
3ccaa710304aef8734a20265ea7fd3dd67d5461c6b3309c6d30d5c7d2a3ae7f9 /efi//26f948d2082e4ae89f5a3af351b63149/6.12.0-rc4+/initrd-dracut
Zbigniew Jędrzejewski-Szmek
Ryan Wilson
Lennart Poettering
Mike Yuan
Yu Watanabe
Nils K
Luca Boccassi
Luca Boccassi
Sebastian Gross
Greg Heartsfield
Daan De Meyer