From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751216AbdATDRo (ORCPT ); Thu, 19 Jan 2017 22:17:44 -0500 Received: from mga05.intel.com ([192.55.52.43]:55671 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751109AbdATDRm (ORCPT ); Thu, 19 Jan 2017 22:17:42 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,257,1477983600"; d="scan'208";a="56097674" Subject: Re: random: /dev/random often returns short reads To: Denys Vlasenko , "Theodore Ts'o" , Denys Vlasenko , Linux Kernel Mailing List References: <20170117043640.4ykofgcwfysvgyue@thunk.org> <20170117171539.dadciiz2kfjtqrfk@thunk.org> <09f2ce2d-3c84-bb12-560c-3208691d2c55@redhat.com> <71338f5a-83e3-4316-845d-8cdea735df0f@linux.intel.com> <2bc270ee-9f42-b4b3-a347-3a7a758d5d1f@redhat.com> <20170118180735.74diazvujsjlqf5m@thunk.org> From: "H. Peter Anvin" Message-ID: <0754295f-b10d-21ce-5767-937d1cd79090@linux.intel.com> Date: Thu, 19 Jan 2017 19:17:41 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/19/17 13:45, Denys Vlasenko wrote: > On Wed, Jan 18, 2017 at 7:07 PM, Theodore Ts'o wrote: >> In the ideal world, yes. I've acknowledged this is a bug, in the "be >> conservative in what you send, liberal in what you receive" sense.. >> But no one complained for three year, and userspace needs to be able >> to retry short reads instead of immediately erroring out. >> >> The problem is changing that code to figure out exactly how many bytes >> you need to get in order to have N random bytes is non-trivial. So >> our choices are: >> >> 1) Transfer more bytes than might be needed to the secondary pool, >> which results in resource stranding --- since entropy in the secondary >> pool isn't available for reseeding the CRNG. OTOH, given that we're >> now using the CRNG solution, and we're only reseeding every five >> minutes, I'm not actually all that worried about stranding some extra >> entropy bits in the blocking pool, since that's only going to happen >> if we have people *using* the /dev/random pool, and so that entropy >> will likely be used eventually anyway > ... > ... >> I'm leaning a bit towards 1 if we have to do something (which is my >> proposed, untested patch). > > Thanks, this solution is okay for me. > That seems to make sense to me as well. -hpa