From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23588 invoked from network); 10 Apr 2022 15:30:52 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Apr 2022 15:30:52 -0000 Received: (qmail 24124 invoked by uid 550); 10 Apr 2022 15:30:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 24092 invoked from network); 10 Apr 2022 15:30:49 -0000 Date: Sun, 10 Apr 2022 11:30:36 -0400 From: Rich Felker To: "Jason A. Donenfeld" Cc: musl@lists.openwall.com Message-ID: <20220410153036.GN7074@brightrain.aerifal.cx> References: <20220409225851.715796-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220409225851.715796-1-Jason@zx2c4.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [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