Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754008AbcDYIYf (ORCPT ); Mon, 25 Apr 2016 04:24:35 -0400 Received: from mail-lf0-f43.google.com ([209.85.215.43]:35279 "EHLO mail-lf0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753663AbcDYIYc (ORCPT ); Mon, 25 Apr 2016 04:24:32 -0400 MIME-Version: 1.0 In-Reply-To: <2009968.Rf1hsrr5t0@tauon.atsec.com> References: <9192755.iDgo3Omyqe@positron.chronox.de> <1499137.D4Mft7n8bh@tauon.atsec.com> <2009968.Rf1hsrr5t0@tauon.atsec.com> From: Nikos Mavrogiannopoulos Date: Mon, 25 Apr 2016 10:23:51 +0200 X-Google-Sender-Auth: cnR34Njfbob45wbQ_Axn_AlPJZM Message-ID: Subject: Re: [RFC][PATCH 0/6] /dev/random - a new approach To: Stephan Mueller Cc: Ted Tso , Herbert Xu , Linux Crypto Mailing List , Linux Kernel Mailing List , Sandy Harris Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 969 Lines: 19 On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller wrote: >> > One more item to consider: If you do not want to change to use >> > getrandom(2), the LRNG provides you with another means. >> The main problem is not about willing to switch to getrandom() or not, >> but finding any system where getrandom() exists. Today due to libc not >> having the call, we can only use /dev/urandom and applications would >> most likely continue to do so long time after getrandom() is >> introduced to libc. > Implement the syscall yourself with syscall(). If you get ENOSYS back, revert > to your old logic of seeding from /dev/urandom. 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. regards, Nikos