From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10806 invoked by alias); 13 Jul 2016 13:10:05 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 10758 invoked by uid 89); 13 Jul 2016 13:10:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=duration, redhatcom, redhat.com, UD:view.php X-HELO: plane.gmane.org To: libc-alpha@sourceware.org From: Nikos Mavrogiannopoulos Subject: Re: [PATCH v2] Add getrandom implementation [BZ #17252] Date: Wed, 13 Jul 2016 13:10:00 -0000 Message-ID: References: <20160610210303.6CE3E40141175@oldenburg.str.redhat.com> <88371300-c533-9886-f1de-e34f17f7cbb4@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit User-Agent: Loom/3.14 (http://gmane.org/) X-SW-Source: 2016-07/txt/msg00358.txt.bz2 Zack Weinberg panix.com> writes: > > On Mon, Jun 27, 2016 at 11:07 AM, Florian Weimer redhat.com> wrote: > > The attached patch does not attempt to make it less likely that the > > getrandom emulation will fail. The file descriptor is kept open only for > > the duration of the call. I move the declaration to (a new > > file) and added some documentation. > > I think it would be better to expose getrandom() as a completely > unadorned syscall. No fallback and no attempt to paper over any of > the infelicities of the kernel interface. > This is because, what with the delay in adding this to libc, there's > existing code now that makes the system call directly. We want people > to be able to just swap in the libc wrapper without having to worry > about behavior differences. I like the patch, though I agree with the statement above. Most likely the emulation layer will create more problems than it would solve. > A reliable cryptographic RNG should _also_ be added, but under a > different name. I'd vote for cloning the BSD arc4random() API. The arc4random API is nice but it has a very unfortunate name. There is some initial effort to standardize via POSIX a similar API: http://austingroupbugs.net/view.php?id=859 regards, Nikos