From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752840AbcFOQRv (ORCPT ); Wed, 15 Jun 2016 12:17:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:47170 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750935AbcFOQRt (ORCPT ); Wed, 15 Jun 2016 12:17:49 -0400 Message-ID: <1466007463.20087.11.camel@redhat.com> Subject: Re: [PATCH v4 0/5] /dev/random - a new approach From: David =?UTF-8?Q?Ja=C5=A1a?= To: Stephan Mueller Cc: Andi Kleen , sandyinchina@gmail.com, Jason Cooper , John Denker , "H. Peter Anvin" , Joe Perches , Pavel Machek , George Spelvin , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 15 Jun 2016 18:17:43 +0200 In-Reply-To: <1668650.acZVSyjHlL@positron.chronox.de> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 15 Jun 2016 16:17:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Stephan, Did you consider blocking urandom output or returning error until initialized? Given the speed of initialization you report, it shouldn't break any userspace apps while making sure that nobody uses predictable pseudoranom numbers. I was considering asking for patch (or even trying to write it myself) to make current urandom block/fail when not initialized but that would surely have to be off by default over "never break userspace" rule (even if it means way too easy security problem with both random and urandom). Properties of your urandom implementation makes this point moot and it could make the random/urandom wars over. Best Regards, David Jaša