Previously, true by validate() means several configs are outdated and we
need to reload configs. That's not intuitive for me. Let's rename the
functions.
Devicetree firmware contains an "aliases" node, containing various
aliases for devices described by the firmware. For ethernet devices,
these are named "ethernet0", "ethernet1", etc. They provide a convenient
means of numbering ethernet devices, especially on systems with no other
stable number other than the address. In particular, U-Boot already uses
these aliases to name its ethernet devices.
Previously, there have been attempts (such as [1]) to add support for
these aliases to Linux. However, these patches have been rejected
because it is the maintainers' view that naming policy be left to
userspace. Well, systemd is userspace, so here we are.
In terms of implementation, apparently there can be multiple device
trees at once. I have decided to dodge this problem for now, and just
use /proc/device-tree. If it is desired to support multiple device trees
later, then the scheme can be modified to include the device tree's
index. For example, /sys/firmware/devicetree/base2/aliases/ethernet3
might be named enb2d3.
For the moment we only support "ethernetX" aliases. Future patches might
want to also handle "canX" and "wifiX".
It is common on boards with only one ethernet device to use an alias of
just "ethernet". In this case, the index is an implicit 0. In case the
author of the firmware made a mistake, we check to ensure that aliases
of "ethernet" and "ethernet0" do not both exist.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezillon@free-electrons.com/Closes: #17625
This makes udevd reload rules only when the timestamp is updated,
even on SIGHUP or `udevadm control --reload`.
So, we can call `udevadm control --reload` without huge performance
penalty when no rules, .link files, and so on are changed.
libblkid gained new tags - FSSIZE, FSLASTBLOCK and FSBLOCKSIZE.
These tags are filesystem related properties probed from superblock.
All of them are enabled by BLKID_SUBLKS_FSINFO flag.
Set the flag to allow these tags to be cached in udev db.
This merges the various labelling calls into a single label_fix_full(),
which can operate on paths, on inode fds, and in a dirfd/fname style
(i.e. like openat()). It also systematically separates the path to look
up in the db from the path we actually use to reference the inode to
relabel.
This then ports tmpfiles over to labelling by fd. This should make the
code a bit less racy, as we'll try hard to always operate on the very
same inode, pinning it via an fd.
User-visibly the behaviour should not change.
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: 8d9156660d
When we start, the contents of the variable match the name. But then
in the loop, the variable doesn't point at the old head any more. So let's
rename it to something with a plural.
This was a trivial wrapper that didn't provide any added value. With more
complicated structures like strvs, hashmaps, sets, and arrays, it is possible
to have an empty container. But in case of a list, the list is empty only when
the head is missing.
Also, we generally want the positive condition, so we replace many
if (!LIST_IS_EMPTY(x)) with just if (x).
Introduce rootpkglibdir for installing libsystemd-{shared,core}.so.
The benefit over using rootlibexecdir is that this path can be
multiarch aware, i.e. this path can be architecture qualified.
This is something we'd like to make use of in Debian/Ubuntu to make
libsystemd-shared co-installable, e.g. for i386 the path would be
/usr/lib/i386-linux-gnu/systemd/libsystemd-shared-*.so and for amd64
/usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-*.so.
This will allow for example to install and run systemd-boot/i386 on an
amd64 host. It also simplifies/enables cross-building/bootstrapping.
For more infos about Multi-Arch see https://wiki.debian.org/Multiarch.
See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
We currently have a convoluted and complex selection of which random
numbers to use. We can simplify this down to two functions that cover
all of our use cases:
1) Randomness for crypto: this one needs to wait until the RNG is
initialized. So it uses getrandom(0). If that's not available, it
polls on /dev/random, and then reads from /dev/urandom. This function
returns whether or not it was successful, as before.
2) Randomness for other things: this one uses getrandom(GRND_INSECURE).
If it's not available it uses getrandom(GRND_NONBLOCK). And if that
would block, then it falls back to /dev/urandom. And if /dev/urandom
isn't available, it uses the fallback code. It never fails and
doesn't return a value.
These two cases match all the uses of randomness inside of systemd.
I would prefer to make both of these return void, and get rid of the
fallback code, and simply assert in the incredibly unlikely case that
/dev/urandom doesn't exist. But Luca disagrees, so this commit attempts
to instead keep case (1) returning a return value, which all the callers
already check, and fix the fallback code in (2) to be less bad than
before.
For the less bad fallback code for (2), we now use auxval and some
timestamps, together with various counters representing the invocation,
hash it all together and provide the output. Provided that AT_RANDOM is
secure, this construction is probably okay too, though notably it
doesn't have any forward secrecy. Fortunately, it's only used by
random_bytes() and not by crypto_random_bytes().
Currently, the systemd-hwdb --root flag only has an effect for the
'update' verb. It would be useful to be able to use the --root option
for the 'query' verb too (e.g. for testing a hwdb.bin created with
systemd-hwdb update --root <path>).
Use sd_hwdb_new_from_path to initialize the hwdb if --root is passed to
systemd-hwdb query.
Note that this functionality was not added to 'udevadm hwdb' since that
command is deprecated.
Without the size limits, oss-fuzz creates huge samples that time out. Usually
this is because some of our code has bad algorithmic complexity. For data like
configuration samples we don't need to care about this: non-rogue configs are
rarely more than a few items, and a bit of a slowdown with a few hundred items
is acceptable. This wouldn't be OK for processing of untrusted data though.
We need to set the limit in two ways: through .options and in the code. The
first because it nicely allows libFuzzer to avoid wasting time, and the second
because fuzzers like hongfuzz and afl don't support .options.
While at it, let's fix an off-by-one (65535 is the largest offset for a
power-of-two size, but we're checking the size here).
Co-authored-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Also break some long lines for more uniform formatting. No functional change.
I went over all log_struct, log_struct_errno, log_unit_struct,
log_unit_struct_errno calls, and they seem fine.
Even if the device node is the same, devnum (thus, device ID) and
syspath may be different. If a 'remove' and 'add' events for the same
device node but with different devnum and syspath are queued,
previously, we might process them in parallel. And, udev_watch_end() for
the 'remove' event and udev_watch_begin() for the 'add' event may
interfere each other.
Previously, a device has DEVPATH_OLD is blocked by a previous event
whose devpath is equivalent to the DEVPATH_OLD.
This extends the condtion.
1. an event has DEVPATH_OLD is blocked by a previous event whose
devpath is a parent of, child of, or equivalent to the DEVPATH_OLD.
2. an event is blocked by a previous event whose DEVPATH_OLD is a
parent of, child of, or equivalent to the devpath of the new event.
I am not sure such check is really necessary. But, the cost of the check
is expected to be extremely small, as device renaming does not occur so
frequently. Hence, it should not introduce any significant performance
regression.
If two devices have the same devnum and subsystem (more specifically,
if the device is block or not), or have the same ifindex, then IDs of
these devices are equivalent.
Hence, the previous conditions are covered by comparing device IDs.
Of course, events with a same ID should be already blocked by the
devpath check. So, this should not change anything.
However, udevd saves many kinds of data under /run/udev named with
the device ID. If multiple workers processes events for the same device
ID, then the database may become corrupted.
Let's explicitly check the device IDs for safety and simplicity.
Yu Watanabe
Richard Phibel
Sean Anderson
Daan De Meyer
Andrey Albershteyn
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
David Tardon
Philipp Gortan
Michael Biebl
Jason A. Donenfeld
Nick Rosbrook
Tomasz Pala