Received: by 10.192.165.156 with SMTP id m28csp918060imm; Fri, 13 Apr 2018 10:02:24 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+eOyfm8gqvFjbZLyLxyV32s+HnBqc8olAFiA0kAOi27QVlXMFJ4ePJBtxXkypnyCvMqwR+ X-Received: by 2002:a17:902:a70c:: with SMTP id w12-v6mr5816845plq.74.1523638943974; Fri, 13 Apr 2018 10:02:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523638943; cv=none; d=google.com; s=arc-20160816; b=JS1mRzZhqCbsFtYPuGJLdIdUguIvmcZ9Xtz26wehWyqPX7CwKldw6gTUf3MRoYZiND tL1DcNMDWhZpoJ1p1OX+el1yMVj2yB+jK1A4mIjqMn04Fp9jgoISwtA0gx5i//+LXRj8 RwBA4YCbPIVa6nvgzDZ9MOGsk89P3ePV1IHjR1TR4qzlAwk+DYBgzQg8yXGwlVLZ6Eji uZNdhwhM2F4nYgsBQvasbq2UMAEVWthLmjlPVKK5H3MB5iSCdL1hptH1gis/azAzhK2u BJLynNyF2tuRXpPZTDM7bgwt9zTExTWFUQZs7UgAIeBs2ObiVdummxa14nn+tz7MOMcs nR9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=U0SKcyOLEesUFZjrplRqusy70q0mBwYPzBsUyETd2rU=; b=Z5R2+Xxz/zxfmEPX9yZortPV5QOGOgz7SeQS1gVslL/hPckjrnDDchritl6WTdeCU2 gRsg2wKwAMdb/WAI+3hAwdnK0+J1BF/xkDq0tYGzMrWOhVmiUPc5guxXblz5FMz5j5vs 6rgGSr7pbvfrtVLh4YApF8YpqdHuQmL3SiCcy1MpXqVhFWgUq0nVpoWpNsjQST0QE4la odJoUFSIJWASFoTuhT+BNRV18IxlzULvynRXFaDwtGsOIHTOmvr3U0dW/PqW5LoVI2OR TPv0vKdtsSzDyBNeH7E1/33NRmqmCt1R8MVlErCEo2IXtD8Qo3iiVT+XcoEZcUqfygNa rJDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=oIZY68Yv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 13si4926992pfm.246.2018.04.13.10.02.09; Fri, 13 Apr 2018 10:02:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=oIZY68Yv; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752464AbeDMRAm (ORCPT + 99 others); Fri, 13 Apr 2018 13:00:42 -0400 Received: from imap.thunk.org ([74.207.234.97]:39616 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750960AbeDMRAl (ORCPT ); Fri, 13 Apr 2018 13:00:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=U0SKcyOLEesUFZjrplRqusy70q0mBwYPzBsUyETd2rU=; b=oIZY68YvjEV4hOG2Vop7ph40qp 76YZzonRAa7ogO31CReSt2+4zDFuESBkkHFHHilVD+Gq7aqkRRqHq1rA7Rh7u40V8rSIsU0dZnNOa gyQzsDombHZ/O5c2gtEFPv/q51zCW0EpldezNsBYJexMcxb2anfdM002lhV6aoyZlfsM=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1f723y-0005ht-7M; Fri, 13 Apr 2018 17:00:38 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 736DF7A2DDF; Fri, 13 Apr 2018 13:00:37 -0400 (EDT) Date: Fri, 13 Apr 2018 13:00:37 -0400 From: "Theodore Y. Ts'o" To: Stephan Mueller Cc: linux-crypto@vger.kernel.org, Linux Kernel Developers List Subject: Re: [PATCH 1/5] random: fix crng_ready() test Message-ID: <20180413170037.GA28721@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Stephan Mueller , linux-crypto@vger.kernel.org, Linux Kernel Developers List References: <20180413013046.404-1-tytso@mit.edu> <1699469.KmO53oa8XU@tauon.chronox.de> <20180413125313.GA2633@thunk.org> <4393662.RPWnPK42dp@tauon.chronox.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4393662.RPWnPK42dp@tauon.chronox.de> User-Agent: Mutt/1.9.4 (2018-02-28) X-SA-Exim-Connect-IP: 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote: > > What I would like to point out that more and more folks change to > getrandom(2). As this call will now unblock much later in the boot cycle, > these systems see a significant departure from the current system behavior. > > E.g. an sshd using getrandom(2) would be ready shortly after the boot finishes > as of now. Now it can be a matter minutes before it responds. Thus, is such > change in the kernel behavior something for stable? It will have some change on the kernel behavior, but not as much as you might think. That's because in older kernels, we were *already* blocking until crng_init > 2 --- if the getrandom(2) call happened while crng_init was in state 0. Even before this patch series, we didn't wake up a process blocked on crng_init_wait until crng_init state 2 is reached: static void crng_reseed(struct crng_state *crng, struct entropy_store *r) { ... if (crng == &primary_crng && crng_init < 2) { invalidate_batched_entropy(); crng_init = 2; process_random_ready_list(); wake_up_interruptible(&crng_init_wait); pr_notice("random: crng init done\n"); } } This is the reason why there are reports like this: "Boot delayed for about 90 seconds until 'random: crng init done'"[1] [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1685794 So we have the problem already. There will be more cases of this after this patch series is applied, true. But what we have already is an inconsistent state where if you call getrandom(2) while the kernel is in crng_init state 0, you will block until crng_init state 2, but if you are in crng_init state 1, you will assume the CRNG is fully initialized. Given the documentation of how getrandom(2) works what its documented guarantees are, I think it does justify making its behavior both more consistent with itself, and more consistent what the security guarantees we have promised people. I was a little worried that on VM's this could end up causing things to block for a long time, but an experiment on a GCE VM shows that isn't a problem: [ 0.000000] Linux version 4.16.0-rc3-ext4-00009-gf6b302ebca85 (tytso@cwcc) (gcc version 7.3.0 (Debian 7.3.0-15)) #16 SMP Thu Apr 12 16:57:17 EDT 2018 [ 1.282220] random: fast init done [ 3.987092] random: crng init done [ 4.376787] EXT4-fs (sda1): re-mounted. Opts: (null) There are some desktops where the "crng_init done" report doesn't happen until 45-90 seconds into the boot. I don't think I've seen reports where it takes _minutes_ however. Can you give me some examples of such cases? - Ted P.S. Of course, in a VM environment, if the host supports virtio-rng, the boot delay problem is completely not an issue. You just have to enable virtio-rng in the guest kernel, which I believe is already the case for most distro kernels. BTW, for KVM, it's fairly simple to set it the host-side support for virtio-rng. Just add to the kvm command-line options: -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0