Currently, when Xen PV domains are nested within a hypervisor which is
detected through CPUID (such as VMware), the detected hypervisor might
not be Xen, because we don't check for Xen until after the CPUID check.
This change moves the Xen check before CPUID checks to fix the issue,
and moves Dom0 checking to detect_vm_xen so that we keep ignoring Xen
when we are in Dom0.
Register a LINUX_EFI_INITRD_MEDIA_GUID DevicePath with a LoadFile2Protocol interface and serve the initrd to a supported Linux kernel (Version 5.8+)
Leave the x86 code for older kernels in place until supported kernels become more mainstream
Let's use the underlying Linux API directly, instead of
opendir()/readdir(). This makes it possible for us to do a single memory
allocation for all directory entries in common cases, instead of one for
each entry.
glibc 2.30 (Aug 2019) added a wrapper for getdents64(). For older
versions let's define our own.
(This syscall exists since Linux 2.4, hence should be safe to use for
us)
Using kernel types __u32 is fine for headers shared by the kernel, but
if we define something in userspace and only use it in userspace, in our
own .c files, let's stick to userspace fixed-length types.
We already did that for sd-boot, hence do it for sd-stub the same way.
Also, move the __attribute__ stuff to the beginning of the statement,
rather than the middle. Mostly just because we usually put it first for
implementations for identifiers (for prototypes we put it last).
ANSI C reserves identifiers beginning with an underscore for compiler
internal stuff. We already invade that namespace plenty and probably
should not. But even going for the doubly underscore prefixed namespace
is a bit too much. Let's just rename the offending table as
"static_signal_table[]", since it lists the static defined signals
rather than the "dynamic" RTSIGMIN/RTSIGMAX signals.
So far we assumed every power source was a battery except for the ones
which definitely are not. I think this logic makes little sense, as
"battery" is kinda the exceptional case here, not the other way round.
Hence let's invert the type check, and denylist "Battery" devices rather
than allowlist "Mains" devices.
This should increase compatibility with alternative types of power
sources, in particular USB ones.
This takes into account that additional power types have been added
since we wrote the original code, and in particular should cover the
siutation discussed here OK:
https://sources.debian.org/src/powermgmt-base/1.36/power_supply.txt/#L31https://sources.debian.org/src/powermgmt-base/1.36/on_ac_power/#L25
Also, modernizes the code in various was ways.
Inspired by and fixes: #20964
Let's add configurable timeout how long to wait for FIDO2/PKCS#11
devices to show up. Once the timeout is hit, let's automatically revert
to querying via passphrase.
Fixes: #19739
Before we'd already ask for a PIN just because we know we'll need it
when the token is plugged in. We'd only the try to talk to the device
and notice it actually isn't plugged in. This is quite confusing, as
querying for the PIN suggests we already had a device we are talking to.
Let's hence check if there's actually device before we ask the PIN
question. And if there is none, let's immediately inform the caller, so
that they watch udev and retry once a device has shown up.
udev: use netlink more aggressively
I'm pasting the comment from https://github.com/systemd/systemd/pull/20744#issuecomment-934485287
which is quite informative. The code wasn't changed significantly since then:
atenart commented 6 days ago:
> I ran tests without (93caec7) and with this PR (06735f2) on Fedora, having a few udev rules
> using attributes eligible to be cached and creating 50 veth on 4 CPUs. Although the time spent
> running the test is variable between runs, I generally saw an improvement when using this PR, e.g:
>
> 249-910-g93caec7:
> real 0m3.691s
> user 0m0.022s
> sys 0m1.338s
>
> 249-920-g06735f2:
> real 0m2.950s
> user 0m0.005s
> sys 0m0.399s
>
> On a different system than the one used above, I even saw a 40% improvement; results depend
> on many parameters (distro, udev rules, concurrent daemons accessing sysfs, etc.).
>
> Because it's quite hard to measure the improvement here (as the kernel behave differently between
> the two test cases), I also ran tests using a modified kernel not hitting the trylock logic. There was
> an improvement with this PR as well. (Take this with a grain of salt though, as the kernel was
> modified not using patches approved upstream).
<limits.h> calls this ULLONG_MAX. It's not clear to me where ULONGLONG_MAX
can be found. This seems to be just a mistake.
Fixes: c7ed718720 ('macro: handle overflow in ALIGN_TO() somewhat reasonably')
People should use homectl to enroll tokens into home directories, hence
point them there. Otherwise the auth data for the account and for the
LUKS volume will end up being different.
Let's use the new crypt_token_max() API in systemd-homework too, to cut
iteration of tokens short.
We already use it in cryptenroll/cryptsetup, so let's use it here too.
Using OpenSSL brings in an additional dependency for all users of
libsystemd.so even though it's just one API that makes use of it.
The khash implementation is awkward as it requires context switches and
computation inside the kernel, thus leaving the process.
Remove both from libsystemd.so, and use exclusively the internal hmac fallback.
While this is not optimized, the sd-id128 API is not used in
performance-critical contexts where hardware acceleration would make a
noticeable difference.
Based on the FIPS 198 specification. Not optimized and probably
completely unsafe, to be used only for non-strong-cryptographic
purposes when OpenSSL cannot be used.
So far we ignored if readdir_ensure_type() failed, the .d_type would
then still possibly report DT_UNKNOWN, possibly confusing the caller.
Let's make this safer: if we get an error on readdir_ensure_type() then
report it — except if it is ENOENT which indicates the dirent vanished
by now, which is not a problem and we should just skip to the next
entry.
Let's ask exactly for the one field we actually want to know, i.e.
STATX_TYPE.
(While we are at it, also copy over the inode number, if we have it,
simply to report the most recent info we have)
(Also, see AT_NO_AUTOMOUNT, so that we don't trigger automounts here.
After all, if we want to know the inode type of a dirent here, then
there's not need to trigger the automount, the inode type is not going
to change by that.)
Apparently glibc already has a helper for this. (Not in the man pages
for Linux, but FreeBSD does document these cryptic helpers, and its
exported by glibc. That should be good enough for us.)
Bogdan Seniuc
Max Resch
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Thomas Haller
Yu Watanabe
(GalaxyMaster)
Luca Boccassi
Jan Janssen
Frantisek Sumsal