linux-kernel - Re: [RFC][PATCH 0/6] /dev/random

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: <c2c67db6-8111-4304-03cd-25d479536d8e@gmail.com>
Date:	Tue, 3 May 2016 11:01:14 -0400
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Nikos Mavrogiannopoulos <nmav@...tls.org>,
	Theodore Ts'o <tytso@....edu>,
	Stephan Mueller <smueller@...onox.de>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Sandy Harris <sandyinchina@...il.com>
Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach

On 2016-05-03 09:57, Nikos Mavrogiannopoulos wrote:
> On Tue, Apr 26, 2016 at 3:11 AM, Theodore Ts'o <tytso@....edu> wrote:
>> On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
>>> That's far from a solution and I wouldn't recommend to anyone doing
>>> that. We cannot expect each and every program to do glibc's job. The
>>> purpose of a system call like getrandom is to simplify the complex use
>>> of /dev/urandom and eliminate it, not to make code handling randomness
>>> in applications even worse.
>> Yes, but if glibc is falling down on the job and refusing to export
>> the system call (I think for political reasons; it's a Linux-only
>> interface, so Hurd wouldn't have it),
>
> I believe their main concern is that they want to protect applications
> which do not check error codes of system calls, when running on a
> kernel which does not provide getrandom().  That way, they have an
> almost impossible task to simulate getrandom() on kernel which do not
> support it.
If it had an existing call, then I could reasonably understand this. 
They have no existing wrapper for it, so this really is just BS.  If an 
application isn't checking error codes, then either:
1. They are intentionally ignoring error codes.
2. It's a bug in the application that needs to be fixed.

The fact that they feel they need to support poorly coded applications 
in _new_ system call wrappers is itself somewhat disturbing.  There are 
no existing applications using this function in glibc because it doesn't 
exist in glibc, which means they can't claim legacy support and 
therefore they want to actively enable people to write stupid programs.