From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1751560AbdAREun (ORCPT <rfc822;w@1wt.eu>);
        Tue, 17 Jan 2017 23:50:43 -0500
Received: from imap.thunk.org ([74.207.234.97]:55884 "EHLO imap.thunk.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751268AbdAREuU (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 17 Jan 2017 23:50:20 -0500
Date: Tue, 17 Jan 2017 23:12:50 -0500
From: "Theodore Ts'o" <tytso@mit.edu>
To: Stephan =?iso-8859-1?Q?M=FCller?= <smueller@chronox.de>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
Subject: Re: [PATCH 3/8] random: trigger random_ready callback upon crng_init
 == 1
Message-ID: <20170118041250.x7wszcasd4dplj3h@thunk.org>
Mail-Followup-To: Theodore Ts'o <tytso@mit.edu>,
        Stephan =?iso-8859-1?Q?M=FCller?= <smueller@chronox.de>,
        linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org
References: <3254875.f5A5oHPdxF@positron.chronox.de>
 <3576149.HSfW5KObBF@positron.chronox.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3576149.HSfW5KObBF@positron.chronox.de>
User-Agent: NeoMutt/20161126 (1.7.1)
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Mail-From: tytso@thunk.org
X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, Dec 27, 2016 at 11:39:57PM +0100, Stephan Müller wrote:
> The random_ready callback mechanism is intended to replicate the
> getrandom system call behavior to in-kernel users. As the getrandom
> system call unblocks with crng_init == 1, trigger the random_ready
> wakeup call at the same time.

It was deliberate that random_ready would only get triggered with
crng_init==2.

In general I'm assuming kernel callers really want real randomness (as
opposed to using prandom), where as there's a lot of b.s. userspace
users of kernel randomness (for things that really don't require
cryptographic randomness, e.g., for salting Python dictionaries,
systemd/udev using /dev/urandom for non-cryptographic, non-security
applications etc.)

						- Ted