From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Lutomirski Subject: Re: [PATCH, RFC] random: introduce getrandom(2) system call Date: Thu, 17 Jul 2014 15:00:45 -0700 Message-ID: References: <1405588695-12014-1-git-send-email-tytso@mit.edu> <20140717161215.GA14951@infradead.org> <20140717170115.GO1491@thunk.org> <20140717204340.GS1491@thunk.org> <20140717214450.GE24196@lenny.home.zabbo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <20140717214450.GE24196-fypN+1c5dIyjpB87vu3CluTW4wlIGRCZ@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Zach Brown Cc: Theodore Ts'o , Bob Beck , Christoph Hellwig , linux-api List-Id: linux-api@vger.kernel.org On Thu, Jul 17, 2014 at 2:44 PM, Zach Brown wrote: > On Thu, Jul 17, 2014 at 04:43:40PM -0400, Theodore Ts'o wrote: > >> So in practice, the fact that we block at system init time shouldn't >> be a hardship for LibreSSL in most cases --- and in the case where you >> are running on an embedded system where there are barely any devices, >> no cycle counter, and nothing that produces enough interrupts to >> initialize the pool, what would you prefer that we do? Return data >> that might not be fully "seed grade entropy"? >> >> If you are determined to get data from a not a fully initialized >> entropy pool, then you can open /dev/urandom and get it via the old >> interface. > > That sounds reasonable. Maybe a slightly edited version of this writeup > could be dropped in the man page to give people context? And we'll be in a sad state in which we have a getrandom(2) syscall but there's no decent way to use srand without either opening /dev/urandom or mucking with AT_RANDOM. And the latter barely works because I think that most (all?) glibc versions clear it after using it to initialize their stack canaries. This isn't a regression, and it isn't a reason to object to getrandom(2), but if getrandom(2) goes in as is, I'll submit a patch adding the new flag immediately. --Andy