Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp4779764imd; Tue, 30 Oct 2018 07:19:37 -0700 (PDT) X-Google-Smtp-Source: AJdET5cKElEBZGcnl8jV2wCjof53WPLTMrZPEtUx1+aFeW/RvncRugpFvi0ZWbRFAooRjpv0Dkwx X-Received: by 2002:a63:4904:: with SMTP id w4-v6mr18172895pga.303.1540909177174; Tue, 30 Oct 2018 07:19:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540909177; cv=none; d=google.com; s=arc-20160816; b=ihBxwWxJmtzABr084TKO1PTiKuqWYqGX14bBku5Szyimw7kjzEJjgsEHzF44kLJWeh 6Mbr8MzaUe9YwCb44nr83+Yz3xiQurT+yTLTlkBJb3r+RS9x9ykaRDyU0H13nlzrBRic ACN/rY0MV7vthXZcH+L/WeEm9CMw4XOw/bcKHsUGTWDy0swIATjo3LEQxiH5h/j2jPBl bnOHjpx5KgC6D5SoRQvgbFxA8oecBm2oxHnagc1n2nRWRGuOU95I/9NDHAqs4l9igE9w 2ujnZjRS/r8gWkE1B5pqcsQXxlZy5Ce66djKL+DoWsbxkp7L9o3DlRBcUwH9h9IwJRiw iOFw== 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; bh=wqnl0Byl/Ja8fcv0nyZPDb2TwWsmDZPb4XrYgH6Yr28=; b=TEjygvt+XCMe6MH1YB2+fWKnu2fA3+PlBc36OhSwA7LLhahu9vKxvDESPBi/7y7LTV tendTl5cW9hI50BuLJphgBMMUmDV+Zexs0krART+EFle9sDMj5sXMGHDFxa5W9XyZ8Mu T/8uFY+C/CQYRUj9vo2KqzOp4DfF8nHN+q41tRWItolLyARYjTGKLnr5/nGGwp8Mi6x7 0qlerviG21ECcmUqo0rlSWzKTM4Miim48NeD5lC8A+A+l4aP7iH9IC0MUENIXeJzcINv XjOG5qT1CNLhmLeD1E9qOGlkzbnEhh9cpCp5U0om7bqFnudosjsDvrNlsH7/sNcaBo93 ePgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=Oqz1dG0b; 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 j7-v6si23182521pgj.532.2018.10.30.07.19.21; Tue, 30 Oct 2018 07:19:37 -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=Oqz1dG0b; 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 S1728280AbeJ3XJ5 (ORCPT + 99 others); Tue, 30 Oct 2018 19:09:57 -0400 Received: from imap.thunk.org ([74.207.234.97]:44006 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728033AbeJ3XJ5 (ORCPT ); Tue, 30 Oct 2018 19:09:57 -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=wqnl0Byl/Ja8fcv0nyZPDb2TwWsmDZPb4XrYgH6Yr28=; b=Oqz1dG0bZsj8bPR3Nwku/KSjZa sPTZpZ5Z6Fwe65xsOqnWE99otK5F42AjGjRJwA2NNAgtR2VjzQXs4Ni/NDJXJxiOPIPiYJRUKsvQN MDM2A9HUTwZE97paaJV5oQWmcU29UAPN6XZPUK34BzgM5WgSZylRABX51lS3BtuXe5Bo=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1gHUo5-0007Jr-0T; Tue, 30 Oct 2018 14:15:45 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 40EC27A45B5; Tue, 30 Oct 2018 10:15:44 -0400 (EDT) Date: Tue, 30 Oct 2018 10:15:44 -0400 From: "Theodore Y. Ts'o" To: Sebastian Andrzej Siewior Cc: Kurt Roeckx , 912087@bugs.debian.org, "Package Development List for OpenSSL packages." , linux-kernel@vger.kernel.org, Bernhard =?iso-8859-1?Q?=DCbelacker?= , pkg-systemd-maintainers@lists.alioth.debian.org, debian-ssh@lists.debian.org, 912087-submitter@bugs.debian.org Subject: Re: Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1 Message-ID: <20181030141544.GE15839@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Sebastian Andrzej Siewior , Kurt Roeckx , 912087@bugs.debian.org, "Package Development List for OpenSSL packages." , linux-kernel@vger.kernel.org, Bernhard =?iso-8859-1?Q?=DCbelacker?= , pkg-systemd-maintainers@lists.alioth.debian.org, debian-ssh@lists.debian.org, 912087-submitter@bugs.debian.org References: <20181029223334.GH10011@roeckx.be> <20181030001807.7wailpm37mlinsli@breakpoint.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181030001807.7wailpm37mlinsli@breakpoint.cc> User-Agent: Mutt/1.10.1 (2018-07-13) 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 Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote: > Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to > /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment > the entropy count after it was written. Those two are documented in > random(4). Or RNDRESEEDCRNG could be used to force crng to be reseeded. > It does also the job, too. > > Ted, is there any best practise what to do with the seed which as > extrected from /dev/urandom on system shutdown? Using RNDADDTOENTCNT to > speed up init or just write to back to urandom and issue RNDRESEEDCRNG? The reason why writing to /dev/[u]random via something like: cat /var/lib/random/seed > /dev/random Dosn't bump the the entropy counter is because it's possible that an attacker could read /var/lib/random/seed. Even if the seed file is refreshed on shutdown, (a) the attacker could have read the file while the system is down, or (b) the system could have crashed so the seed file was not refreshed and the attacker could have read the file before the crash. If you are using a VM, if the host has virtio-rng, using a kernel that has virtio-rng support will solve the problem. For qemu, this means you can enable via something like this: -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 If you are using Google Compute Engine, I can't comment about future product features, but I would encourage you to file a feature request bug with Google requesting virtio-rng support ASAP. On any VM (cloud or on-prem), since you have to trust the host *anyway*, with v4.19, you can add random.trust_cpu=on to the boot command-line, or build the kernel with CONFIG_RANDOM_TRUST_CPU. For the Debian 4.18 kernel, this can be backported via commits 39a8883a2b98 and 9b25436662d5. - Ted