The current code uses lose_counter to make more attempts to read
random numbers. It seems better to wait a moment between attempts to
avoid busy loop (we do the same in all-io.h).
The worst case is 1 second delay for all random_get_bytes() on systems
with uninitialized entropy pool -- for example you call sfdisk (MBR Id
or GPT UUIDs) on very first boot, etc. In this case it will use libc
rand() as a fallback solution.
Note that we do not use random numbers for security sensitive things
like keys or so. It's used for random based UUIDs etc.
Addresses: https://github.com/karelzak/util-linux/pull/603
Signed-off-by: Karel Zak <kzak@redhat.com>
In Endless we have hit a problem when using 'sfdisk' on the really first
boot to automatically expand the rootfs partition. On this platform
'sfdisk' is blocking on getrandom() because not enough random bytes are
available. This is an ARM platform without a hwrng.
We fix this passing GRND_NONBLOCK to getrandom(). 'sfdisk' will use the
best entropy it has available and fallback only as necessary.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
The getrandom() does not have to return all requested bytes (missing
entropy or when interrupted by signal). The current implementation in
util-linux stupidly asks for all random data again, rather than only
for missing bytes.
The current code also does not care if we repeat our requests for
ever; that's bad.
This patch uses the same way as we already use for reading from
/dev/urandom. It means:
* repeat getrandom() for only missing bytes
* limit number of unsuccessful request (16 times)
* fallback to /dev/urandom on ENOSYS (old kernel or so...)
Addresses: https://github.com/karelzak/util-linux/issues/496
Signed-off-by: Karel Zak <kzak@redhat.com>
If getrandom() is called with nbytes ≥ 256 then it can return with less than the requested
bytes filled.
In this case we *could* adjust the buffer by the number of bytes actually read, but it's
simpler to just redo the call.
The 3.16 kernel is supported until 2020, and various distros have kernels of the same
vintage. It's entirely possible for code built against newer headers to be run against
these kernels, so fall-back to the old “read /dev/{u,}random” method if the kernel doesn'
support getrandom()
text-utils/tailf.c:69:21: warning: Using plain integer as NULL pointer
Since many 'struct option' has used zero as NULL make them more readable in
same go by reindenting, and using named argument requirements.
Reference: https://lwn.net/Articles/93577/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
System call getrandom(2) is relatively new, available since kernel 3.17 but
not supported by glibc 2.24. That in mind autotools is made to check
availability of this function and keep old code as fallback. It is
reasonable assume it will take years before the syscall(2) and fallback are
unproblematic to remove.
One might ask why bother using getrandom(2). Main reason is to avoid
unnecessary system calls to achieve exactly same end result. That
demonstrated with 'strace -c ./mcookie' showing 36 calls before, and 32
after this change. Secondly the getrandom(2) function got to kernel with
promise it can be used to avoid file descriptor run down, and since uuidd
uses random_get_bytes() it should fulfill it's promise here.
Reference: http://man7.org/linux/man-pages/man2/getrandom.2.html
Reference: https://lwn.net/Articles/606141/
Reviewed-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
The mcookie should reuse existing code, and there is definitely no need
to prefer /dev/random for this utility. See reference for explanation
about later statement.
References: http://www.2uo.de/myths-about-urandom/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
We use the code from include/ and lib/ on many places, so use public
domain if possible or LGPL for code copied from libs.
Signed-off-by: Karel Zak <kzak@redhat.com>
This reverts commit 6126f7a53c
and fixes the double open and leaking descriptor in a different way,
that is by using newly introduced function 'have_random_source()'
to check whether good random source is available while deciding
which uuid type to generate (random/time).
This is better than calling random_get_fd() twice, passing the file
descriptor down the stack and reusing it in next call to
random_get_fd().
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
We are opening /dev/urandom twice in uuid_generate(): first to check if
the file is available and then later __uuid_generate_random() again to
actually get the random data. Moreover, descriptor from the first open
is leaking.
Fix by passign the descriptor down the stack and reusing it there.
References: http://marc.info/?l=util-linux-ng&m=133406051131131&w=2
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
Add a random number(s) generator specific file. The intial functions are based
on what libuuid provide. I did some modifications like avoid WIN32 checks - this
is util-LINUX.
[kzak@redhat.com: - move jrand_seed to lib/randutils.c
- use TLS for jrand_seed (like original code from libuuid)
- use size_t for buffer sizes
- add close() to random_get_bytes]
Signed-off-by: Davidlohr Bueso <dave@gnu.org>
Signed-off-by: Karel Zak <kzak@redhat.com>