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>
