[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220410153036.GN7074@brightrain.aerifal.cx>
Date: Sun, 10 Apr 2022 11:30:36 -0400
From: Rich Felker <dalias@...c.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH v2] getentropy: fail if buffer not completely
filled
On Sun, Apr 10, 2022 at 12:58:49AM +0200, Jason A. Donenfeld wrote:
> The man page for getentropy says that it either completely succeeds or
> completely fails, and indeed this is what glibc does. However, musl has
> a condition where it breaks out of the loop early, yet still returns a
> success. This patch fixes that by returning a success only if the buffer
> is completely filled.
It does not return success if it breaks out of the loop early. In that
case ret is -1 and it returns -1 (return ret;).
The loop is necessary by my understanding of the function not because
of the possibility of short reads (which shouldn't be able to happen)
but because EINTR can happen while blocking before the urandom pool is
ready. In theory we could probably rip out the non-EINTR part of the
logic (partial reads) but if it's already there and working it seems
like it's not harming anything and serves as hardening against the
kernel doing something stupid.
Is there a remaining problem you're trying to solve?
Rich
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.
