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.
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".
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.
It makes more sense to call VXLAN ID as
1. the VXLAN Network Identifier (VNI) (or VXLAN Segment ID)
2. test-network: rename VXLAN Id to VNI
3. fuzzer: Add VXLAN VNI directive to fuzzer
