Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp1587163ybc; Sun, 17 Nov 2019 03:12:47 -0800 (PST) X-Google-Smtp-Source: APXvYqzaLAnVwRaUtCoydRW0CGrj9TwIcDJMEwTJ73lIuS3z0rSDxaPu1QJR5ouWPMOBmr2hppvp X-Received: by 2002:a17:906:8307:: with SMTP id j7mr16690135ejx.171.1573989166917; Sun, 17 Nov 2019 03:12:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573989166; cv=none; d=google.com; s=arc-20160816; b=z09wlp9OMvswFJF+tuIuCXY5EE0KsURgOZUKOMRs+2gXsUGlfclzhhLhRuPnakRXZK +nBnP2a7MFr30jqhfKvK4cNjwtCuGzMScxiabLgatiqQfy5/9wDziwEOWjsFLffhpzSN +IjNvchDamyz7jzztpSUARMr3A6BBbWU8H7cIN/4/YqCnpuxKRFZM0TpRTNb2nFuKWjV MkLas/uYXlUO8BRy4KmdJ4NI/hs9gDPZ4Sj4r1kYwbZoVGt0PaJg0/oVXzlilpCfIGvA BHvo7f9mh/BsfPbRoYQxklyt6sjEUcy6t+99nRZFupQWikDvmFgQFRGuH8GqeF096owP 9kSQ== 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:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=MT2mPjdD45S2F5oIRqRGfpRXIEr/oEzDuVVP6bvuysY=; b=VILjWBa0lJR6B+3IJBTxYpoBCdy6/2hZpN7mmewSEXTH59oI9oxC5Lo0MclGAB02Ey 1n++/Yj0pAiy58JoUV9yp6Ue3FerdOTuMeAfYpfnS1KqrP+b0mzHPHIbO3LXaverdMrj pVkIshrGLQUQXFQqOiW6lGZNRFCDWvmBHgwtJuauyVyHpASVyO46oh2khBR+U1aS6yj7 nf69zE5C1objLFFwhWZSP9XBZDx2d4deeW9C1yMAWt3KVhbjLfjQi3gZItC80s2cU3Zj A5lcaYyI4Y11HuIXpTwSj33cDSsg0phUCuxMZNivKOGVxuW1h14+IFuFp7woH0h2gAPA cmzA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@chronox.de header.s=strato-dkim-0002 header.b=XYGEUR0I; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-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 br3si9379788ejb.436.2019.11.17.03.12.21; Sun, 17 Nov 2019 03:12:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-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=@chronox.de header.s=strato-dkim-0002 header.b=XYGEUR0I; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726028AbfKQLMS (ORCPT + 99 others); Sun, 17 Nov 2019 06:12:18 -0500 Received: from mo4-p03-ob.smtp.rzone.de ([85.215.255.101]:34882 "EHLO mo4-p03-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725974AbfKQLMS (ORCPT ); Sun, 17 Nov 2019 06:12:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1573989134; s=strato-dkim-0002; d=chronox.de; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=MT2mPjdD45S2F5oIRqRGfpRXIEr/oEzDuVVP6bvuysY=; b=XYGEUR0I70hDP+Si0+//TM3DvsCZs8BveedNchYb+NiCRDeDTaXebHcnuGvQq/cJ/O aiy2kz1B87gM+Ja3zlqie5cRm2DNt1fwh7j6m0il4RVZu5UrvBC5Qa/rW3LjZ/Rr7sQ8 WxvaBVOUpQjdXar++wQFnA1Gij4SXedW0DvSf4pMES8BxMj5V3lPeiXOPzQV+1EIbxdh 95pJvDh4U0NyX3IpkiVBtuUkiRwA5Xouqd0tHbuWWtTq/zYSsOoNqmpP7xNDu1v9Mi2f jlPWX3S3afFP/i6U8mYjq4ZEQtZdPlZfSalkRpGo1mvH+tZNEcdjJMZ8TuSJOvG6CONP DtWg== X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzHHXDbIvSfb0y2" X-RZG-CLASS-ID: mo00 Received: from positron.chronox.de by smtp.strato.de (RZmta 44.29.0 DYNA|AUTH) with ESMTPSA id N09a57vAHBB6VUM (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Sun, 17 Nov 2019 12:11:06 +0100 (CET) From: Stephan =?ISO-8859-1?Q?M=FCller?= To: Andy Lutomirski Cc: Arnd Bergmann , Greg Kroah-Hartman , linux-crypto@vger.kernel.org, LKML , linux-api@vger.kernel.org, "Eric W. Biederman" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Willy Tarreau , Matthew Garrett , Vito Caputo , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , Andy Lutomirski , Florian Weimer , Lennart Poettering , Nicolai Stange , "Peter, Matthias" , Marcelo Henrique Cerri , Roman Drahtmueller , Neil Horman Subject: Re: [PATCH v25 10/12] LRNG - add TRNG support Date: Sun, 17 Nov 2019 12:10:58 +0100 Message-ID: <3159012.PsEOTp9LqO@positron.chronox.de> In-Reply-To: References: <5390778.VeFRgus4bQ@positron.chronox.de> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Am Samstag, 16. November 2019, 17:09:09 CET schrieb Andy Lutomirski: Hi Andy, > > On Nov 16, 2019, at 1:40 AM, Stephan M=C3=BCller = wrote: > >=20 > > =EF=BB=BFThe True Random Number Generator (TRNG) provides a random numb= er > > generator with prediction resistance (SP800-90A terminology) or an NTG.1 > > (AIS 31 terminology). >=20 > ... >=20 > > The secondary DRNGs seed from the TRNG if it is present. In addition, > > the /dev/random device accesses the TRNG. > >=20 > > If the TRNG is disabled, the secondary DRNGs seed from the entropy pool > > and /dev/random behaves like getrandom(2). >=20 > As mentioned before, I don=E2=80=99t like this API. An application that,= for some > reason, needs a TRNG, should have an API by which it either gets a TRNG or > an error. Similarly, an application that wants cryptographically secure > random numbers efficiently should have an API that does that. With your > design, /dev/random tries to cater to both use cases, but one of the use > cases fails depending on kernel config. >=20 > I think /dev/random should wait for enough entropy to initialize the syst= em > but should not block after that. A TRNG should have an entirely new API > that is better than /dev/random. I apologize for the misunderstanding. I assumed we would introduce such /de= v/ true_random at a later stage. If you agree, I can certainly add /dev/true_random right now that links wit= h=20 the TRNG and make /dev/random behave as discussed, i.e. behave exactly like= =20 getrandom(..., 0); As this would introduce a new device file now, is there a special process t= hat=20 I need to follow or do I need to copy? Which major/minor number should I us= e? Looking into static const struct memdev devlist[] I see [8] =3D { "random", 0666, &random_fops, 0 }, [9] =3D { "urandom", 0666, &urandom_fops, 0 }, Shall a true_random be added here with [10]? Ciao Stephan