Susant Sahani [Fri, 10 May 2019 12:17:45 +0000 (17:47 +0530)]
LLDP: Fix logs for LLDP
```
May 10 11:08:54 test systemd-networkd[447]: wwan0: Failed to stop LLDP: Success
May 10 11:08:54 test systemd-networkd[447]: wwan0: Gained carrier
May 10 11:08:54 test systemd-networkd[447]: wwan0: Failed to start LLDP: Success
```
The comment in udev-builtin-net_id.c (removed in grandparent commit) showed the
property without the prefix. I assume that was always the intent, because it
doesn't make much sense to concatenate anything to an arbitrary user-specified
field.
I decided to make this a separate man page because it is freakin' long.
This content could equally well go in systemd-udevd.service(8), systemd.link(5),
or a new man page for the net_id builtin.
v2:
- rename to systemd.net-naming-scheme
- add udevadm test-builtin net_id example
journalctl: add new --relinquish and --smart-relinquish options
The latter is identical to the former, but becomes a NOP if
/var/log/journal is on the same mount as /, and thus during shutdown
unmounting /var is not necessary and hence we can keep logging until the
very end.
This adds a minimal Varlink (https://varlink.org/) implementation to our
tree. Given that we already have a JSON logic it's an easy thing to add.
Why bother?
We currently have major problems with IPC before dbus-daemon is up, and
in all components that dbus-daemon itself makes use of (such as various
NSS modules to resolve users as well as the journal which dbus-daemon
logs to). Because of that we so far ended up creating various (usually
crappy) work-arounds either coming up with secondary IPC systems or
sharing data statelessly in /run or similar. Let's clean this up, and
instead use a clean, well-defined, broker-less IPC for cases like that.
This is a minimal implementation of Varlink, i.e. the most basic logic
only. Stuff that's missing is left out on purpose: there's no
introspection/validation and there's no name service. It might make
sense to add that later, but for now let's only do the minimum buy-in we
can get away with. In particular as I'd assume that at least initially
we only use this IPC for our internal communication avoiding
introspection and the name service should be fine.
Specifically, I'd expect that we add IPC interfaces to the following
concepts with this scheme:
1. nss-resolve (so that hostname lookups with resolved work before
resolved is up)
2. journald (so that IPC calls to journald don't have to go through
dbus-daemon thus creating a cyclic dependency between journald and
dbus-daemon)
3. nss-systemd (so that dynamic user lookups via PID 1 work sanely even
inside of dbus-daemon, because otherwise we'd want to use dbus to run
dbus which causes deadlocks)
4. networkd (to make sure one can talk to it in the initrd already,
long before dbus is around)
Certain distributions (e.g. Arch Linux) require booting with initrd, as
they lack support for commonly used filesystems in the kernel (i.e. the
support is compiled in as modules)
Susant Sahani [Wed, 8 May 2019 17:01:08 +0000 (22:31 +0530)]
networkd: VXLAN add support to configure IP Don't fragment.
Allow users to set the IPv4 DF bit in outgoing packets, or to inherit its
value from the IPv4 inner header. If the encapsulated protocol is IPv6 and
DF is configured to be inherited, always set it.
Susant Sahani [Thu, 9 May 2019 02:05:35 +0000 (07:35 +0530)]
networkd: fix link_up() (#12505)
Fillup IFLA_INET6_ADDR_GEN_MODE while we do link_up.
Fixes the following error:
```
dummy-test: Could not bring up interface: Invalid argument
```
After reading the kernel code when we do a link up
```
net/core/rtnetlink.c
IFLA_AF_SPEC
af_ops->set_link_af(dev, af);
inet6_set_link_af
if (tb[IFLA_INET6_ADDR_GEN_MODE])
Here it looks for IFLA_INET6_ADDR_GEN_MODE
```
Since link up we didn't filling up that it's failing.
Otherwise, the fuzzers will fail to compile with MSan:
```
../../src/systemd/src/basic/random-util.c:64:40: error: use of undeclared identifier 'sucess'; did you mean 'success'?
msan_unpoison(&success, sizeof(sucess));
^~~~~~
success
../../src/systemd/src/basic/alloc-util.h:169:50: note: expanded from macro 'msan_unpoison'
^
../../src/systemd/src/basic/random-util.c:38:17: note: 'success' declared here
uint8_t success;
^
1 error generated.
[80/545] Compiling C object 'src/basic/a6ba3eb@@basic@sta/process-util.c.o'.
ninja: build stopped: subcommand failed.
Fuzzers build failed
```
In program output, highlighting warnings with ANSI_HIGHLIGHT is not enough,
because it doesn't stand out enough. Yellow is more appropriate.
I was worried that yellow wouldn't be visible on white background, but (at
least gnome-terminal) uses a fairly dark yellow that is fully legible on white
and light-colored backgrounds. We also used yellow in many places,
e.g. systemctl, so this should be fine.
Note: yellow is unreadable on urxvt with white background (urxvt +rv). But
grey, which we already used, is also unreadable, so urxvt users would have
to disable colors anyway, so this change does not make the problem
intrinsically worse. See
https://github.com/systemd/systemd/issues/12482#issuecomment-490374210.
When emitting the calendarspec warning we want to see some color.
Follow-up for 04220fda5c.
Exceptions:
- systemctl, because it has a lot hand-crafted coloring
- tmpfiles, sysusers, stdio-bridge, etc, because they are also used in
services and I'm not sure if this wouldn't mess up something.
random-util: hash AT_RANDOM getauxval() value before using it
Let's be a bit paranoid and hash the 16 bytes we get from getauxval()
before using them. AFter all they might be used by other stuff too (in
particular ASLR), and we probably shouldn't end up leaking that seed
though our crappy pseudo-random numbers.
The old flag name was a bit of a misnomer, as /dev/urandom cannot be
"drained". Once it's initialized it's initialized and then is good
forever. (Only /dev/random has a concept of 'draining', but we never use
that, as it's an obsolete interface).
The flag is still useful though, since it allows us to suppress accesses
to the random pool while it is not initialized, as that trips up the
kernel and it logs about any such attempts, which we really don't want.
scsi_serial: replace some crazy strncpy() calls by strnlen()
gcc was warning about strncpy() leaving an unterminated string.
In this case, it was correct.
The code was doing strncpy()+strncat()+strlen() essentially to determine
if the strings have expected length. If the length was correct, a buffer
overread was performed (or at least some garbage bytes were used from the
uninitialized part of the buffer). Let's do the length check first and then
only copy stuff if everything agrees.
For some reason the function was called "prepend", when it obviously does
an "append".
shared/utmp-wtmp: silence gcc warning about strncpy truncation
Unfortunately the warning must be known, or otherwise the pragma generates a
warning or an error. So let's do a meson check for it.
Is it worth doing this to silence the warning? I think so, because apparently
the warning was already emitted by gcc-8.1, and with the recent push in gcc to
catch more such cases, we'll most likely only get more of those.
Yu Watanabe [Sat, 4 May 2019 18:03:44 +0000 (20:03 +0200)]
network: fix conditional jump depends on uninitialised value(s)
When address is in IPv4, the remaining buffer in in_addr_union may
not be initialized.
Fixes the following valgrind warning:
```
==13169== Conditional jump or move depends on uninitialised value(s)
==13169== at 0x137FF6: UnknownInlinedFun (networkd-ndisc.c:77)
==13169== by 0x137FF6: UnknownInlinedFun (networkd-ndisc.c:580)
==13169== by 0x137FF6: ndisc_handler.lto_priv.83 (networkd-ndisc.c:597)
==13169== by 0x11BE23: UnknownInlinedFun (sd-ndisc.c:201)
==13169== by 0x11BE23: ndisc_recv.lto_priv.174 (sd-ndisc.c:254)
==13169== by 0x4AA18CF: source_dispatch (sd-event.c:2821)
==13169== by 0x4AA1BC2: sd_event_dispatch (sd-event.c:3234)
==13169== by 0x4AA1D88: sd_event_run (sd-event.c:3291)
==13169== by 0x4AA1FAB: sd_event_loop (sd-event.c:3313)
==13169== by 0x117401: UnknownInlinedFun (networkd.c:113)
==13169== by 0x117401: main (networkd.c:120)
==13169== Uninitialised value was created by a stack allocation
==13169== at 0x1753C8: manager_rtnl_process_address (networkd-manager.c:479)
```
Yu Watanabe [Sat, 4 May 2019 17:43:45 +0000 (19:43 +0200)]
network: fix use-after-free
The function sd_radv_add_prefix() in dhcp6_pd_prefix_assign() may
return -EEXIST, and in that case the sd_radv_prefix object allocated
in dhcp6_pd_prefix_assign() will be freed when the function returns.
Hence, the key value in Manager::dhcp6_prefixes hashmap is lost.
Susant Sahani [Thu, 2 May 2019 09:52:03 +0000 (15:22 +0530)]
networkd: manager do not unef netlink and gennetlink early
Because of this the fd is getting closed and we getting errors
like
```
^Ceno1: Could not send rtnetlink message: Bad file descriptor
enp7s0f0: Could not send rtnetlink message: Bad file descriptor
enp7s0f0: Cannot delete unreachable route for DHCPv6 delegated subnet 2a0a:...:fc::/62: Bad file descriptor
Assertion '*_head == _item' failed at ../systemd/src/network/networkd-route.c:126, function route_free(). Aborting.
Aborted
```
Closes one of https://github.com/systemd/systemd/issues/12452
projects / thirdparty / systemd.git / log
