RANDOM_BLOCK has existed for a long time, but RANDOM_ALLOW_INSECURE was
added more recently, leading to an awkward relationship between the two.
It turns out that only one, RANDOM_BLOCK, is needed.
RANDOM_BLOCK means return cryptographically secure numbers no matter
what. If it's not set, it means try to do that, but if it fails, fall
back to using unseeded randomness.
This part of falling back to unseeded randomness is the intent of
GRND_INSECURE, which is what RANDOM_ALLOW_INSECURE previously aliased.
Rather than having an additional flag for that, it makes more sense to
just use it whenever RANDOM_BLOCK is not set. This saves us the overhead
of having to open up /dev/urandom.
Additionally, when getrandom returns too little data, but not zero data,
we currently fall back to using /dev/urandom if RANDOM_BLOCK is not set.
This doesn't quite make sense, because if getrandom returned seeded data
once, then it will forever after return the same thing as whatever
/dev/urandom does. So in that case, we should just loop again.
Since there's never really a time where /dev/urandom is able to return
some easily but more with difficulty, we can also get rid of
RANDOM_EXTEND_WITH_PSEUDO. Once the RNG is initialized, bytes
should just flow normally.
This also makes RANDOM_MAY_FAIL obsolete, because the only case this ran
was where we'd fall back to /dev/urandom on old kernels and return
GRND_INSECURE bytes on new kernels. So also get rid of that flag.
Finally, since we're always able to use GRND_INSECURE on newer kernels,
and we only fall back to /dev/urandom on older kernels, also only fall
back to using RDRAND on those older kernels. There, the only reason to
have RDRAND is to avoid a kmsg entry about unseeded randomness.
The result of this commit is that we now cascade like this:
- Use getrandom(0) if RANDOM_BLOCK.
- Use getrandom(GRND_INSECURE) if !RANDOM_BLOCK.
- Use /dev/urandom if !RANDOM_BLOCK and no GRND_INSECURE support.
- Use /dev/urandom if no getrandom() support.
- Use RDRAND if we would use /dev/urandom for any of the above reasons
and RANDOM_ALLOW_RDRAND is set.
On Ubuntu CI on ppc64el, the test randomly fails when /run/udev is not
synced before checking its contents (see #22357). But /run/udev is a
tmpfs and fsync on tmpfs is noop (see `struct shmem_file_operations` in
mm/shmem.c of the kernel), hence, it is not necessary to call fsync on
/run/udev in general. This should be a testing emvironment issue (I
guess it is an issue on nested KVM on ppc64el), instead of an issue on
udev.
C.f. #22357.
Fixes#21603.
This can help users to figure out what makes systemd freeze.
1. Someone kills systemd accidentally, then the sender_pid won't be 1;
2. systemd triggers segfault or assert, then the sender_pid will be 1;
When writing docs for SD_BUS_VTABLE_CAPABILITY, I noticed that we have one use
of SD_BUS_VTABLE_CAPABILITY(CAP_SYS_ADMIN) in the tree. This is the default, so
it's not very useful to specify it. But if we're touching that, I think it's
better to use mac + polkit for this like for everything else.
We don't have a very good category for this, but I don't think it makes sense
to add a new one. I just reused the same as other similar calls.
Some SCSI tape devices use the same device ID (NAA registered device
designator) for the SCSI tape changer device and the first actual tape
device. For example, this one:
https://docs.oracle.com/en/storage/tape-storage/storagetek-sl150-modular-tape-library/slofs/bridged-tape-drives.html
You must connect the bridged drive to an HBA supporting multiple
LUNs (also referred to as LUN scanning). The SL150 Library uses a
single SCSI ID and two logical unit numbers (LUN). LUN 0 controls
the tape drive and LUN 1 which is configured as a SCSI medium
changer device controls the robotics. Data is sent to the remaining
LUN on the bridged drive or to LUNs on the other, unbridged drives
in the partition, all of which are configured as SCSI
sequential-access (tape) devices.
This may lead to errors because /dev/tape/by-id symlinks may sometimes
point to the st device representing the tape, and sometimes to the sg
device representing the changer.
Fix this by assigning an increased priority to the tape device, and creating
a separate -changer link for the SCSI tape changer.
Co-developed-by: Martin Wilck <mwilck@suse.com>
In some BIOSes, the "Number of slots or sockets available for Memory
Devices in this array" is incorrectly set to the number of memory array
that's populated.
Work-around this problem by outputting the number of sockets after
having parsed them so that consumers of this data can carry on expecting
an accurate number in this property.
This fixes the number of memory slots advertised for the HP Z600.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1686
The complaint was that the output array was used for two kinds of data, and the
input flag decided whether this extra data should be included. The flag is
removed, and instead the old method is changed to include the data always as
a separate parameter.
This breaks backward compatibility, but the old method is effectively broken
and does not appear to be used yet, at least in open source code, by
searching on codesearch.debian.net and github.com.
Fixes#22404.
Co-authored-by: Luca Boccassi <bluca@debian.org>
IIUC, pipefail doesn't matter for a sequence of commands joined with &&, and we
don't have any pipes. And such a failing expression also does not trigger an
exit, so the set +e/set -e were noops.
The brightness control key (Fn+F7 Fn+F8) and touchpad toggle key (Fn + Space) do not work on the NEC VersaPro VG-S laptop. Add the keycode to fix the problem.
Make sure our RPM macros work as intended. Based on the original PR
(#16464) by Mikhail Novosyolov.
Co-authored-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
I think the current behaviour is stupid: 'x-systemd.automount,noauto' should
mean that we create the units, but don't add .mount or .automount to any targets.
Instead, we completely ignore 'noauto'. But let's at least describe the
implementation.
Text suggested by dpartrid in the bug.
Fixes#21040.
A description of SD_BUS_VTABLE_CAPABILITY is added, and the discussion
on SD_BUS_VTABLE_UNPRIVILEGED in expanded. I think it would be nice
to add longer description of how access is checked (maybe in sd-bus(3)),
but I'm leaving that for later. I think the text that was added here
describes everything, even if tersely.
Fixes#21882.
docbook would convert the newline to a space before the first argument:
SD_BUS_METHOD_WITH_ARGS( member, args, result, handler)
And we need each item in a separate <para>, otherwise they'll all be in
one line.
The data type off_t can be 64 on 32 bit systems if they have large
file support. Since mmap expects a size_t with 32 bits as second
argument truncation could occur. At worst these huge files could
lead to mmaps smaller than the previous check for small files.
This in turn shouldn't have a lot of impact because mmap allocates
at page size boundaries. This also made the PAGE_ALIGN call in
open_mmap unneeded. In fact it was neither in sync with other mmap
calls nor with its own munmap counterpart in error path.
If such large files are encountered, which is very unlikely in these
code paths, treat them with the same error as if they are too small.
The approach to use '''…'''.split() instead of a list of strings was initially
used when converting from automake because it allowed identical blocks of lines
to be used for both, making the conversion easier.
But over the years we have been using normal lists more and more, especially
when there were just a few filenames listed. This converts the rest.
No functional change.
Add dlopen_dw(), dlopen_elf() and dlopen_pcre2() to the dlopen test.
To enable adding dlopen_pcre2(), we move pcre2-dlopen.h/c from
src/journal to src/shared.
file-hierarchy does not mention anything about the expected mountpoint
for cgroups. This may lead some software to believe it will need to
search for it (e.g. by scanning mountinfo) rather than just looking in
the canonical location.
Document the canonical mountpoint as /sys/fs/cgroup. Also provide
information on the non-default configurations, but
make it clear that in such configurations if cgroup2 is mounted (hybrid
mode) it won't have resource controllers attached. This will help
software know if it should fall back to /sys/fs/cgroup/unified or just
ignore that case.
The fall-through to reboot doesn't seem to make sense. It won't happen
in the current code. Filtering the actions on client side is not needed
either as the server will refuse unsupported operations anyway.
Yu Watanabe
Temuri Doghonadze
Lennart Poettering
Jason A. Donenfeld
Laura Barcziova
licunlong
Zbigniew Jędrzejewski-Szmek
David Bond
tawefogo
Luca Boccassi
Ludwig Nussel
Frantisek Sumsal
Bastien Nocera
Daan De Meyer
4piu
David Tardon
Alfonso Sánchez-Beato
Tobias Stoeckmann
dependabot[bot]
Josh Triplett