From: Pavel Machek Subject: Re: [PATCH -v4] random: introduce getrandom(2) system call Date: Wed, 30 Jul 2014 14:26:20 +0200 Message-ID: <20140730122620.GC13965@amd.pavel.ucw.cz> References: <1405718127-30042-1-git-send-email-tytso@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-crypto@vger.kernel.org, beck@openbsd.org, deraadt@cvs.openbsd.org To: Theodore Ts'o Return-path: Content-Disposition: inline In-Reply-To: <1405718127-30042-1-git-send-email-tytso@mit.edu> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-crypto.vger.kernel.org Hi! > The rationale of this system call is to provide resiliance against > file descriptor exhaustion attacks, where the attacker consumes all > available file descriptors, forcing the use of the fallback code where > /dev/[u]random is not available. Since the fallback code is often not > well-tested, it is better to eliminate this potential failure mode > entirely. I'm not sure I understand the rationale; if someone can eat all your file descriptors, he can make you stop working. So you can just stop working when you can't open /dev/urandom, no? Fallback code is probably very bad idea to use... > The other feature provided by this new system call is the ability to > request randomness from the /dev/urandom entropy pool, but to block > until at least 128 bits of entropy has been accumulated in the > /dev/urandom entropy pool. Historically, the emphasis in the > /dev/urandom development has been to ensure that urandom pool is > initialized as quickly as possible after system boot, and preferably > before the init scripts start execution. Sounds like ioctl() for /dev/urandom for this behaviour would be nice? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html