Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDERwrLPpg4acOM4tAv0xu3dAqSe3EnLUH36homn3mBHEkYrA@mail.gmail.com>
Date: Wed, 28 Jan 2015 11:43:17 -0600
From: Brent Cook <busterb@...il.com>
To: musl@...ts.openwall.com
Subject: Re: getrandom syscall

Here is the wrapper in LibreSSL for getrandom, to hopefully lend to
the discussion:

https://github.com/libressl-portable/openbsd/blob/master/src/lib/libcrypto/crypto/getentropy_linux.c#L194

It tries to avoid a couple of possible issues. FIrst, while <= 256
byte getrandom should not interrupt, it appears that if the kernel
entropy pool has not been initialized yet, it would still return EINTR
if called early enough in the boot process. How likely this is in
practice, I don't know.

Then, to avoid modifying errno even though there was an actual
success, the wrapper restores the previous errno value when it
succeeds.

I just realized that the length check in getentropy_getrandom() is
redundant, since it is checked earlier in getentropy() as well, but
hopefully this is helpful.

If a getentropy() were added to musl libc, but in such a way that it
might fail on older kernels, that would cause some problems with
LibreSSL, and now OpenNTPD. They will both try to use getentropy()
with arc4random() if it is found in a system, and arc4random() will
treat a getentropy() failure as fatal.

Thanks, and good discussion.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.