Previously, when comparing an existing and requested routing policy
rules, `all` flag was unset, thus the from and to addresses in the two
rules were not compared. Hence, a new request with from and/or to
addresses might be considered as it already exists even the addresses of
existing one were different from the newly requested one.
All existing rules have valid family, i.e. AF_INET or AF_INET6. And,
all requesting rules with from and/or to addresses also have a valid
family. Hence, even `all` flag is unset, the addresses can be and must
be compared in that case.
Fixes a regression caused by fc58350aa4 (v257).
Fixes#35874.
This is advanced level stuff that regular contributors don't care
about in the slightest, so move it further down. Also reword the
section a little while we're at it.
The test commands now use mkosi sandbox which always makes sure the
required dependencies for systemd-journal-remote are enabled so no
need to reconfigure meson explicitly anymore.
With 19812661f1, we make sure at runtime
in the stub itself that SizeOfImage from the Linux EFISTUB PE binary is
taken into account, so there's no need to take this into account in ukify
itself. By reverting the ukify change, we again ensure that Misc_VirtualSize
reflects the actual size of the Linux EFISTUB PE binary in the .linux section
which lots of tooling depends on. It also makes sure we don't measure a bunch
of extra zeroes in the stub which should fix systemd-pcrlock measurements as
well.
This effectively reverts 2188c759f9 and
0005411352.
Fixes#35851
The UKI file has to be writable to be able to do boot counting in
the UEFI firmware which involves renaming the file by writing to
the file metadata which requires the file to be writable in the FAT
filesystem.
Fixes#36170
Update osCPE field example to use cpe 2.3 format, as is in active use by
AmazonLinux 2023 for example.
Add appCPE field example to document the upstream application CPE for
the applicable CVEs. Often distribution source package names are
different from the upstream CPE. For example adding/removing "lib"
prefix, or adding version stream "-3" suffix. This typically leads to
guessing or fuzzy matching. Adding appCPE in such cases can help to
disambiguate (or collate) correct application CPEs; especially beyond
the lifetime of osCPE support timeframes. This also will help a lot with
packaging multiple alternative source packages of the same software
(e.g. nginx-full nginx-core); different version streams (e.g.
openssl-1.1, openssl-3); or alternative builds of upstream software with
largely the same CVEs with multiple version streams (e.g.
openjdk-{22,17,11..}, corretto-{22,17,11..}, temurin-{22,17,11..}, etc).
Update osCPE field example to use cpe 2.3 format, as is in active use by
AmazonLinux 2023 for example.
Add appCPE field example to document the upstream application CPE for the
applicable CVEs. Often distribution source package names are different from the
upstream CPE. For example adding/removing "lib" prefix, or adding version
stream "-3" suffix. This typically leads to guessing or fuzzy matching. Adding
appCPE in such cases can help to disambiguate (or collate) correct application
CPEs; especially beyond the lifetime of osCPE support timeframes.
We should only use Misc_VirtualSize if it's smaller than SizeOfRawData,
since in that case it'll be the non-aligned section size. Otherwise we
have to use SizeOfRawData to get the size on disk.
UKIs can be used to bundle uefi firmwares that can be measured and
used on a confidential computing environment. There can be more than one
firmware blob bundle, each one for a specific platform. Also firmware images
can themselves be containers like IGVM files that can in turn bundle the
actual firmware blob. This change is specifically for uefi firmwares, not
IGVM container files.
This change adds support to introduce a .efifw section in UKI that can be
used for firmware blobs/images. There can be multiple such sections and each
section can contain a single firmware image.
The matching .hwids entry for a specific platform can be used to select the
most appropriate firmware blob.
ukify tool has been also changed to support addition of a firmware image
in UKI.
Since firmware gets measured automatically, we do not need to measure it
separately as a part of the UKI.
Commit 1be9b30a3b ("dhcp6: use dns_name_from_wire_format") introduced a
stricter validation of domains received via DHCPv6, by using function
dns_name_from_wire_format() which rejects the domain when it is missing the
terminating zero label. According to RFC 4704 § 4.2, DHCPv6 servers should
always add the zero label:
To send a fully qualified domain name, the Domain Name field is set
to the DNS-encoded domain name including the terminating zero-length
label. To send a partial name, the Domain Name field is set to the
DNS-encoded domain name without the terminating zero-length label.
[...]
Servers SHOULD send the complete fully qualified domain name in
Client FQDN options.
In practice, there is at least on common DHCPv6 server implementation (dnsmasq)
that sends the FQDN option without the ending zero-length label; after
upgrading to the new systemd, the client cannot parse the option and therefore
the machine doesn't get the hostname provided by dnsmasq.
This commit restores the old behavior that considers a domain valid even when
it's missing the terminating zero label.
Here's a quick reproducer:
--8<--
ip link add veth0 type veth peer name veth1
ip netns add ns1
ip link set veth1 netns ns1
ip link set veth0 address 00:11:22:33:44:55
ip link set veth0 up
ip -n ns1 link set veth1 up
ip -n ns1 address add dev veth1 fd01::1/64
ip netns exec ns1 dnsmasq \
--pid-file=/tmp/dnsmasq.pid --no-hosts \
--bind-interfaces --interface veth1 --except-interface lo \
--dhcp-range=fd01::100,fd01::200 --enable-ra \
--dhcp-host 00:11:22:33:44:55,foobar &
cat <<EOF > /etc/systemd/network/veth0.network
[Match]
Name=veth0
[Network]
DHCP=ipv6
EOF
networkctl reload
networkctl up veth0
sleep 5
hostname
--8<--
Without this change, systemd-networkd prints the following message and doesn't
set the hostname from DHCP:
veth0: DHCPv6 client: Failed to parse FQDN option, ignoring: Bad message
PCR 7 covers the SecureBoot policy, in particular "dbx", i.e. the
denylist of bad actors. That list is pretty much as frequently updated
as firmware these days (as fwupd took over automatic updating). This
means literal PCR 7 policies are problematic: they likely break soon,
and are as brittle as any other literal PCR policies.
hence, pick safer defaults, i.e. exclude PCR 7 from the default mask.
This means the mask is now empty.
Generally, people should really switch to signed PCR policies covering
PCR 11, in combination with systemd-pcrlock for the other PCRs.
This is printed by bus_manager_log_shutdown() in logind-dbus.c,
near the start of the shutdown process.
Clarify that events *will* happen, long after this message is sent.
This message appears when a computer hibernates, then awakens, then reboots,
and everything goes OK. It's a normal progress message the user doesn't need
to know about, but it distracts them from important startup messages and could
even train them to ignore the warning when the procedure fails.
Reduce the level to LOG_INFO.
PCR 7 covers the SecureBoot policy, in particular "dbx", i.e. the
denylist of bad actors. That list is pretty much as frequently updated
as firmware these days (as fwupd took over automatic updating). This
means literal PCR 7 policies are problematic: they likely break soon,
and are as brittle as any other literal PCR policies.
hence, pick safer defaults, i.e. exclude PCR 7 from the default mask.
This means the mask is now empty.
Generally, people should really switch to signed PCR policies covering
PCR 11, in combination with systemd-pcrlock for the other PCRs.