libgcrypt: random source via library on Linux?

[Steffen Nurpmeso]

Werner Koch via Gnupg-users wrote in
<87y2p5pzkl.fsf at wheatstone.g10code.de>:
 |On Fri, 29 May 2020 17:54, Steffen Nurpmeso said:
 |> Looking at the source it seems libgcrypt knows about the Linux
 |> getrandom systemcall.  Yet it does not seem to know about glibc's
 |> getrandom library function.
 |
 |Which was not available back then when I implemented support for
 |getrandom.  Further; there is no guarantee that getrandom(2) is
 |supported on all machines.  We care a lot about backward compatibility
 |and can't simply demand a certain Linux kernel or glibc version.

That was understood even before seeing the file history.  Sure.

 |> i would change, maybe with a new call-in to rndlinux.c which
 |> should be made responsible for Linux-only environmental detections
 |
 |You don't change audited RNG code if there is not a very good reason for
 |that.

Well, sometimes you do :)

Getting rid of any file descriptors when the actual kernel allows
to do so is i think an improvement that should be thought about.

Localizing module-specific availability tests to the module itself
is also a step in a good direction.

I personally think that taking out the only optional available
getentropy thing out of the random read loop to its own top-level
code block is also a good thing, it was foreign matter and seems
to have been patched in (it does not anticipate in block locals
and uses continue; to skip over the originally sole loop content).
The loop condition is "length != 0", this condition is tested
multiple times in this function.

Also, in the past getentropy has been tried each and every time
the function was called, even if it was actually not available.
Each time the loop ticked, to be more exact.  That is really hard.
With the patch this is a setup condition just as the availability
test for /dev/*random.  (Which is not even tried occasionally.)

The change in _gcry_rngdrbg_close_fds() is of course totally
unrelated, but i want to point out that all other functions which
call _gcry_rndlinux_gather_random() directly do the locking cycle
even if USE_RNDLINUX is not defined.  (In fact i personally would
move all the locks into the #ifdef but i have no idea of this
codebase :-).)

I admit that RANDOM_CONF_ONLY_URANDOM functionality is not
restored, but for that the autotools stuff had to be adjusted, and
the code would become more complex (getrandom has to be called
directly on Linux, then, which needs sys/random.h to reach out for
GRND_NONBLOCK).  On OpenBSD however, getentropy() is identical to
getrandom(,, GRND_RANDOM) on Linux.

And i personally think [17f246c7] is not needed, the system call
guarantees atomic delivery if <256 are requested, OpenBSD even
forces this maximum.  These sytem calls fail if the number of
bytes cannot be delivered (atomically).

Ciao from and to Germany!  And to Japan and all the rest, too, of
course,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)