An ugly, ugly work-around for #11810. And no, we shouldn't have to do
this. This is something for AMD, the firmware or the kernel to
fix/work-around, not us. But nonetheless, this should do it for now.
Fixes: #11810
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.
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.
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.
This is another attempt at d4b604baea and #12438
Instead of blindly using the extra allocated space, let's do so only
after telling libc about it, via a second realloc(). The second
realloc() should be quick, since it never has to copy memory around.
This reverts commit d4b604baea.
When realloc() is called, the extra memory between the originally
requested size and the end of malloc_usable_size() isn't copied. (at
least with the version of glibc that currently ships on Arch Linux)
As a result, some elements get lost and use uninitialized memory, most
commonly 0, and can lead to crashes.
fixes#12384
If a container manager does not set $container, we could end up
in a strange situation when detect-virt returns container-other when
run as non-pid-1 and none when run as pid-1.
So apparently there are two reasons why accept() can return EOPNOTSUPP:
because the socket is not a listening stream socket (or similar), or
because the incoming TCP connection for some reason wasn't acceptable to
the host. THe latter should be a transient error, as suggested on
accept(2). The former however should be considered fatal for
flush_accept(). Let's fix this by explicitly checking whether the socket
is a listening socket beforehand.
kernel-4.15's if_ether.h has a bug that the header does not provide
'struct ethhdr'. The bug is introduced by
6926e041a8920c8ec27e4e155efa760aa01551fd (4.15-rc8)
and fixed by da360299b6734135a5f66d7db458dcc7801c826a (4.16-rc3).
This makes systemd built with kernel-4.15 headers.
Fixes#12319.
The L2TP_ATTR_UDP_ZERO_CSUM6_{TX,RX} attributes are introduced by
6b649feafe10b293f4bd5a74aca95faf625ae525, which is included in
kernel-3.16. To support older kernel, let's import the header.
Fixes#12300.
Now linux/in.h has better conflict detection with glibc's
netinet/in.h. So, let's import the headers.
Note that our code already have many workarounds for the conflict,
but in this commit does not drop them. Let's do that in the later
commits if this really helps.
This is partially a refactoring, but also makes many more places use
unlocked operations implicitly, i.e. all users of fopen_temporary().
AFAICT, the uses are always for short-lived files which are not shared
externally, and are just used within the same context. Locking is not
necessary.
We had all kinds of indentation: 2 sp, 3 sp, 4 sp, 8 sp, and mixed.
4 sp was the most common, in particular the majority of scripts under test/
used that. Let's standarize on 4 sp, because many commandlines are long and
there's a lot of nesting, and with 8sp indentation less stuff fits. 4 sp
also seems to be the default indentation, so this will make it less likely
that people will mess up if they don't load the editor config. (I think people
often use vi, and vi has no support to load project-wide configuration
automatically. We distribute a .vimrc file, but it is not loaded by default,
and even the instructions in it seem to discourage its use for security
reasons.)
Also remove the few vim config lines that were left. We should either have them
on all files, or none.
Also remove some strange stuff like '#!/bin/env bash', yikes.
This is modelled after the existing ERRNO_IS_RESOURCES() and in
particular ERRNO_IS_DISCONNECT(). It returns true for all transient
network errors that should be handled like EAGAIN whenever we call
accept() or accept4(). This is per documentation in the accept(2) man
page that explicitly says to do so in the its "RETURN VALUE" section.
The error list we cover is a bit more comprehensive, and based on
existing code of ours. For example EINTR is included too (since we need
that to cover cases where we call accept()/accept4() on a blocking
socket), and of course ERRNO_IS_DISCONNECT() is a bit more comprehensive
than the list in the man page too.
No technical reason, except that later on we want to add a new
ERRNO_IS() which uses the parameter twice and where we want to avoid
double evaluation, and where we'd like to keep things in the same style.
