Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp2888334imm; Wed, 16 May 2018 23:01:35 -0700 (PDT) X-Google-Smtp-Source: AB8JxZo7SMO+IfnwKzwNaNHK4bPqnm3Bd23a2S/ZN1U7JaOTk6me+IQXHB6DlArGVp9tgffDthD/ X-Received: by 2002:a17:902:8d8c:: with SMTP id v12-v6mr3875442plo.366.1526536895195; Wed, 16 May 2018 23:01:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526536895; cv=none; d=google.com; s=arc-20160816; b=RUwGjUYXgsyJ6hslLmZUb827uKYGOp+xE4mwCSMePQftPo10JyTYQk5HxDDHHl13yf hpS3r5sET4U2zhWrQpQKAwfoikF/BSgQKYYrqTfBdihnMaJwgejeQ+Is0bLKBxWUDRly FfBboBn7g0bKqPLNAUzx3C6awAwkmmotUSowMSHLUa64J6YUOuPnMa+XngVvBc8WoJZv oX8s/KvzQ0XJHVMSRhCxkuUsZGYyobwCzDwN2AgeQ0YzH9KRj8k0ol8RNkyAtb28wwhX 8GEGjuzhE4idfRI/RnrvE0B0Epuio3aecBC1CskO0kyYYb/th2lv0NSOXodRodv1MvXy C9Yg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=QFXmpmdNGg3oKivnYvosKp6K6mvCg4Fg8XX7DdoV+vI=; b=E5Pjt3NVlhxubUSy1WiywW9WylcMoLC+gU3z42kEB+wMaG/nYeLqxSUg+A+QOGCGLU 85ZxDsAKjRK8hEKuG2zMYDX5HDK8Gs97riYQq+2s5ea06nbou6JZL+087fD811ezz6Ud 2uabDTkr6ZA8ALaTMhncaBORS+wDQ8JbcOLKEWz0wR8OKIfDsifG+pE8tYP+Hz1imJST QVM2up3/lJ+i4kfadWzjTWwfoaiICFwbxpAMgXk3WT0VoSJi3htmSyzEi7BfysSVPUc3 v2Z5rHqljNtgviZaIcNZHtuOw2st/G1f/HBHakizLldlW52Z0yURXy0+H7uD25E20Zkf h+rQ== ARC-Authentication-Results: i=1; mx.google.com; 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 l3-v6si4344372pfi.179.2018.05.16.23.01.20; Wed, 16 May 2018 23:01:35 -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; 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 S1751322AbeEQGBI (ORCPT + 99 others); Thu, 17 May 2018 02:01:08 -0400 Received: from pegase1.c-s.fr ([93.17.236.30]:29184 "EHLO pegase1.c-s.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750801AbeEQGBG (ORCPT ); Thu, 17 May 2018 02:01:06 -0400 Received: from localhost (mailhub1-int [192.168.12.234]) by localhost (Postfix) with ESMTP id 40mgf7410Hz9txfX; Thu, 17 May 2018 08:01:03 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at c-s.fr Received: from pegase1.c-s.fr ([192.168.12.234]) by localhost (pegase1.c-s.fr [192.168.12.234]) (amavisd-new, port 10024) with ESMTP id ByYn56sLKqDu; Thu, 17 May 2018 08:01:03 +0200 (CEST) Received: from messagerie.si.c-s.fr (messagerie.si.c-s.fr [192.168.25.192]) by pegase1.c-s.fr (Postfix) with ESMTP id 40mgf73Tfmz9txfT; Thu, 17 May 2018 08:01:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 566868B82C; Thu, 17 May 2018 08:01:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at c-s.fr Received: from messagerie.si.c-s.fr ([127.0.0.1]) by localhost (messagerie.si.c-s.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id CtayuUBSGXD6; Thu, 17 May 2018 08:01:04 +0200 (CEST) Received: from PO15451 (po15451.idsi0.si.c-s.fr [172.25.231.2]) by messagerie.si.c-s.fr (Postfix) with ESMTP id 1F1F38B75B; Thu, 17 May 2018 08:01:04 +0200 (CEST) Subject: Re: [PATCH 1/5] random: fix crng_ready() test 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> <20180413170037.GA28721@thunk.org> From: Christophe LEROY Message-ID: <84e0c16c-2b48-69e5-4ca4-2ca3bce15dc9@c-s.fr> Date: Thu, 17 May 2018 08:01:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180413170037.GA28721@thunk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 13/04/2018 à 19:00, Theodore Y. Ts'o a écrit : > 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? On a powerpc embedded board which has an mpc8xx processor running at 133Mhz, I now get the startup done in more than 7 minutes instead of 30 seconds. This is due to the webserver blocking on read on /dev/random until we get 'random: crng init done': [ 0.000000] Linux version 4.17.0-rc4-00415-gd2f75d40072d (root@localhost) (gcc version 5.4.0 (GCC)) #203 PREEMPT Wed May 16 16:32:02 CEST 2018 [ 0.295453] random: get_random_u32 called from bucket_table_alloc+0x84/0x1bc with crng_init=0 [ 1.030472] device: 'random': device_add [ 1.031279] device: 'urandom': device_add [ 1.420069] device: 'hw_random': device_add [ 2.156853] random: fast init done [ 462.007776] random: crng init done This has become really critical, is there anything that can be done ? Christophe > > - 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 >