From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26467C432C3 for ; Tue, 19 Nov 2019 10:07:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id F1FFF2230F for ; Tue, 19 Nov 2019 10:07:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574158076; bh=raQvysGezMOTdzZhLbXQVgeelzwMcf+XsBZN45+Jnr4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=BxlaSKWpdnsJ1RnAWvbLggrX6Tkm3GnZJ9KW/U+rEZOMb9DJxu/6sOQBBWZsyznuY teLjXvYcTnOYuAY1MhLrFay3dmnfyJfw5yyBOMeAaRYd9fnA4uNlVdvd2Vkyd/VoOL jRoTPf5ZEddKjxBF6zbd4yY1X5ZxYqemrDnCD+Kg= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727472AbfKSKHz (ORCPT ); Tue, 19 Nov 2019 05:07:55 -0500 Received: from mail.kernel.org ([198.145.29.99]:41622 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725280AbfKSKHy (ORCPT ); Tue, 19 Nov 2019 05:07:54 -0500 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5F43A2230C for ; Tue, 19 Nov 2019 10:07:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1574158073; bh=raQvysGezMOTdzZhLbXQVgeelzwMcf+XsBZN45+Jnr4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=RjQMR4rU1In9lM+kAb4soSF9t2AJfvrcdffTs2mzM8uL6Cad3vzhxR46A+cnPjzxn IbVrdWOO3lWPGCxxz4HG/NKbdQqe5Ky2v0SIN7DghQNfbG7hDIRteoctcksF2NfgXM RG9O1yHUUaXaQFTAOb31qHoXc7t73yJh86cTH7t8= Received: by mail-wr1-f53.google.com with SMTP id e6so23109623wrw.1 for ; Tue, 19 Nov 2019 02:07:53 -0800 (PST) X-Gm-Message-State: APjAAAXV++htogJqemXvoZQCaqct9LQpWISwhQImqn2iiLGjRb/qfMSI lFdlaur9zyGBfBM7cb+5H4T9btnM6S5+aBO0uO4oBg== X-Google-Smtp-Source: APXvYqzIDjHYabEFDKNGNz1GeBkQRlFBAp+pdbYkngDyg4rogH0rFpf7wiaTn8LWmx1If1ARFOOJ5Qjs8JwSWm8TNDM= X-Received: by 2002:a5d:490b:: with SMTP id x11mr34652314wrq.111.1574158071890; Tue, 19 Nov 2019 02:07:51 -0800 (PST) MIME-Version: 1.0 References: <5390778.VeFRgus4bQ@positron.chronox.de> <3159012.PsEOTp9LqO@positron.chronox.de> In-Reply-To: <3159012.PsEOTp9LqO@positron.chronox.de> From: Andy Lutomirski Date: Tue, 19 Nov 2019 02:07:40 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v25 10/12] LRNG - add TRNG support To: =?UTF-8?Q?Stephan_M=C3=BCller?= Cc: Arnd Bergmann , Greg Kroah-Hartman , Linux Crypto Mailing List , LKML , Linux API , "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 17, 2019 at 3:11 AM Stephan M=C3=BCller w= rote: > > 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: > > > > > > =EF=BB=BFThe True Random Number Generator (TRNG) provides a random nu= mber > > > generator with prediction resistance (SP800-90A terminology) or an NT= G.1 > > > (AIS 31 terminology). > > > > ... > > > > > The secondary DRNGs seed from the TRNG if it is present. In addition, > > > the /dev/random device accesses the TRNG. > > > > > > If the TRNG is disabled, the secondary DRNGs seed from the entropy po= ol > > > and /dev/random behaves like getrandom(2). > > > > As mentioned before, I don=E2=80=99t like this API. An application tha= t, 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 you= r > > design, /dev/random tries to cater to both use cases, but one of the us= e > > cases fails depending on kernel config. > > > > I think /dev/random should wait for enough entropy to initialize the sy= stem > > 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 /= dev/ > true_random at a later stage. > > If you agree, I can certainly add /dev/true_random right now that links w= ith > the TRNG and make /dev/random behave as discussed, i.e. behave exactly li= ke > getrandom(..., 0); Given that your series is already a decently large ABI change, I think it would be polite to users to make all the anticipated changes all at once to reduce the amount of churn everyone needs to deal with. > > As this would introduce a new device file now, is there a special process= that > I need to follow or do I need to copy? Which major/minor number should I = use? > > 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]? I am not at all an expert on chardevs, but this sounds generally reasonable. gregkh is probably the real authority here.