linux-kernel - Re: random: /dev/random often returns short reads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7c128925-a4d8-dda4-b9f9-597902d752be@linux.intel.com>
Date:   Tue, 17 Jan 2017 17:54:18 -0800
From:   "H. Peter Anvin" <hpa@...ux.intel.com>
To:     Theodore Ts'o <tytso@....edu>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Denys Vlasenko <vda.linux@...glemail.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: random: /dev/random often returns short reads

On 01/17/17 15:41, Theodore Ts'o wrote:
> On Tue, Jan 17, 2017 at 02:29:30PM -0800, H. Peter Anvin wrote:
>> If there is a real need to hack around this, then I would instead
>> suggest modifying random_read() to block rather than return if the user
>> requests below a certain value, O_NONBLOCK is not set, and the whole
>> request cannot be fulfilled.  It probably needs to be a sysctl
>> configurable, though, and most likely defaulting to 1, as it could just
>> as easily break properly functioning applications.
> 
> Ugh.  This seems horribly complicated.  If we _really_ need to give
> aid and comfort to people trying to do pointless FIPS certification
> workarounds (as opposed to closing bugzilla complaints with "working
> as intended"), how about this?

Personally I'm fine with your parenthesized solution, and we can always
tell them that the workaround for their broken app is to mount
/dev/urandom over /dev/random until they have fixed their software.  ;)

	-hpa