Received: by 10.192.165.148 with SMTP id m20csp2810976imm; Sun, 29 Apr 2018 07:31:40 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpxWr67sdnsKRS76R4vtEW1de4iGTiqGuR+idsRcfFt36ty8debXWsk6rycJAy+52lTR/z4 X-Received: by 2002:a17:902:5402:: with SMTP id d2-v6mr9385250pli.386.1525012299963; Sun, 29 Apr 2018 07:31:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525012299; cv=none; d=google.com; s=arc-20160816; b=gbOZFeba6nWJTR5Mnv68XSuXBFNexCjTYCcjLKS8cGHuUIS2H5hU/2yCEQOJYbgY2K 974cYAM6Xyl4hv/rHVA9vbYvlaOnhAA835Y390510Mctv6D4P8qC+LnHTENFmWb0nbDF B5PS85gVmLA/+ebjmn4Ck93g0bJXGsW9QWtK0uRmq/Zwc14Oe2dzg9rire/GnW5AXJwt JtIS94909s4ZwF8sA8HaptqCdTnCXHCAuovNSelDBiy6/OXXi9C39kv3zc9/DnlPuqvf sQwiXfypqr8BGIeJP1yPtstKxX72ToYTzCCW4PXxykkZ93pdgJx1GPHxK3+s3aUA6gli GDHg== 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:message-id:subject:to :from:date:arc-authentication-results; bh=58+rCFkqtRWMhZEJZ+3AYd7D1JOGrNs1y9VaQRLG2r4=; b=lMF0HTCJRYiUoFG7ODcE/Qn+8ACtCbWz4bMWdPIGO0+VTLVH+IA+Z7plxt1Zj5SxxV J+cNAeckJh4mT3Vk57k+UCR789VJjeVxH3mrkpfD4XDyjPgF5j/vEWvFRESr2eZEtODw +EriP5i3e6OIAQ4NYU7pcNUabMqcLL1wsrhPkV9aHIL6L4M++jw8F8AzF7kHdfWgmStR v11JW8SJ4fMeK5QgGzUqAT7Vj+lcQK/JkSvtwb76Tteu2fzPrsB32pBpZQy5q39zIURv iQz8sL+7c1H0Y3yVFDGD1WG4tNbXHc05nl/8Sk7LFEHEUfrGayEO8LFMvhZHK43LNlw6 6KBw== 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 x7-v6si4862506pge.559.2018.04.29.07.31.25; Sun, 29 Apr 2018 07:31:39 -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 S1753440AbeD2O37 (ORCPT + 99 others); Sun, 29 Apr 2018 10:29:59 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:52280 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752895AbeD2O36 (ORCPT ); Sun, 29 Apr 2018 10:29:58 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id CDE738044C; Sun, 29 Apr 2018 16:29:56 +0200 (CEST) Date: Sun, 29 Apr 2018 16:29:56 +0200 From: Pavel Machek To: "Theodore Y. Ts'o" , Sultan Alsawaf , linux-kernel@vger.kernel.org, Jann Horn Subject: Re: Linux messages full of `random: get_random_u32 called from` Message-ID: <20180429142956.GB13475@amd> References: <20180426050056.GF18803@thunk.org> <20180426073255.GH18803@thunk.org> <20180426192524.GD5965@thunk.org> <2add15cb-2113-0504-a732-81255ea61bf5@gmail.com> <20180426235630.GG5965@thunk.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <20180426235630.GG5965@thunk.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! On Thu 2018-04-26 19:56:30, Theodore Y. Ts'o wrote: > On Thu, Apr 26, 2018 at 01:22:02PM -0700, Sultan Alsawaf wrote: > >=20 > > Also, regardless of what's hanging on CRNG init, CRNG should be able to= init on its own in a timely > > manner without the need for user-provided entropy. Userspace was workin= g fine before the recent CRNG > > kernel changes, so I don't think this is a userspace bug. >=20 > The CRNG changes were needed because were erroneously saying that the > entropy pool was securely initialized before it really was. Saying > that CRNG should be able to init on its own is much like saying, "Ted > should be able to fly wherever he wants in his own personal Gulfstream > V." It would certainly be _nice_ if I could afford my personal jet. > I certainly wish I were that rich. But the problem is that dollars > (or Euro's) are like entropy, they don't just magically drop out of > the sky. >=20 > If there isn't user-provided entropy, and the hardware isn't providing > sufficient entropy, where did you think the kernel is supposed to get > the entropy from? Should it dial 1-800-TRUST-NSA? Yes, we could dial 1-800-TRUST-NSA. Then nicely ask them to provide us some unbackdoored randomness. Then we'd ignore whatever they say, but would collect randomness from timing and noise on the telephone line. > The other approach would be to compile the kernel with > CONFIG_HW_RANDOM_TPM and to modify drivers/char/tpm/tpm-chip.c tot > initalize chip->hwrng.quality =3D 500. We've historically made this > something that the system administrator must set via sysfs. This is > because we wanted system adminisrators to explicitly say that they > trust the any hardware manufacturer that (a) they haven't been paid by > your choice of the Chinese MSS or the US NSA to introduce a backdoor,i > and (b) they are competent to actually implemnt a _secure_ hardware > random number generator. Sadly, this has not always been the case. Well, we could actively start accessing suitable device (SD card ? HDD ? CMOS RTC?) when we detect entropy is low. Yes, that would eat power, but that would be better than machine that hangs at boot. We could also access the hwrng, then collect entropy from the timing. TPM is slow chip... Pav= el --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlrl1uQACgkQMOfwapXb+vJg6gCfSaQ4ccTbDjF3fz8H+dm9PPQ1 CO8An3zEePRGgPTlgLaRafOwnx/tg0lC =07R6 -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R--