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=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 E62FCC432C3 for ; Wed, 20 Nov 2019 09:00:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C01372245F for ; Wed, 20 Nov 2019 09:00:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=chronox.de header.i=@chronox.de header.b="WHD6KRcp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728060AbfKTJAL (ORCPT ); Wed, 20 Nov 2019 04:00:11 -0500 Received: from mo4-p02-ob.smtp.rzone.de ([85.215.255.82]:21320 "EHLO mo4-p02-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728030AbfKTJAK (ORCPT ); Wed, 20 Nov 2019 04:00:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1574240408; 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=FO60nC3S+oDIpCbZRvJjF5XfVNeQtlqMONqUWv0+n+4=; b=WHD6KRcpmfGt41cmracVFI7LHG2nA6QOu3C+28vmgLw3T/XxqCT3xmZntU3rx60nqT eP4dyq4w/MyBt3YYmVnpx1TUsq9s6WhTsy96GisjhqF2hzam+YztM3Ac8oVAn63NTuEG lJHd3pajGXUZA6Bp34W5+5dR1q8WzGyiDVix3r6tXNR5DjeXtWWvcflmRfIZy6zqz0Yt uwEsx4pZNUp8Rc5bEdMZVH1YuOY3o9w2kFOHcbtNRpmKECk2afF4RnYvwmxGHONEMjrq Stx3hZqPbAsHp7qG8q8DYWrXB+fETzKzLcP5Fim6wn/dQAAIofSODr4350yaxzv39lTw Nl5g== X-RZG-AUTH: ":P2ERcEykfu11Y98lp/T7+hdri+uKZK8TKWEqNyiHySGSa9k9xmwdNnzHHXDbL/ScbtM=" X-RZG-CLASS-ID: mo00 Received: from positron.chronox.de by smtp.strato.de (RZmta 44.29.0 DYNA|AUTH) with ESMTPSA id N09a57vAK8wajR4 (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); Wed, 20 Nov 2019 09:58:36 +0100 (CET) From: Stephan =?ISO-8859-1?Q?M=FCller?= To: Greg Kroah-Hartman Cc: Andy Lutomirski , Arnd Bergmann , 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 , 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: Wed, 20 Nov 2019 09:58:35 +0100 Message-ID: <19681012.svDddlc5pN@positron.chronox.de> In-Reply-To: <20191119124150.GB1975017@kroah.com> References: <5390778.VeFRgus4bQ@positron.chronox.de> <20191119124150.GB1975017@kroah.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Dienstag, 19. November 2019, 13:41:50 CET schrieb Greg Kroah-Hartman: Hi Greg, > On Tue, Nov 19, 2019 at 02:07:40AM -0800, Andy Lutomirski wrote: > > > 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] = { "random", 0666, &random_fops, 0 }, > > > [9] = { "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. > > [10] is the aio char device node, so you better not try to overlap it or > bad things will happen :( Thanks for your insights. Which device minor number could we use? Or another idea and apologies if I restart this conversation as there was already a discussion around it: what about extending the getrandom(2) call instead of adding a device file? What about adding yet another flag to getrandom: GRND_TRUERANDOM and process it as follows: if (flags & ~(GRND_NONBLOCK|GRND_RANDOM|GRND_INSECURE| GRND_TRUERANDOM)) return -EINVAL; //From Andy's tree /* * Requesting insecure and blocking randomness at the same time makes * no sense. */ if ((flags & (GRND_INSECURE|GRND_RANDOM)) == (GRND_INSECURE| GRND_RANDOM)) return -EINVAL; /* We only allow GRND_TRUERANDOM by itself or with NONBLOCK */ if (! ((flags & GRND_TRUERANDOM) && ((flags == GRND_TRUERANDOM) || (flags == GRND_TRUERANDOM | GRND_NONBLOCK)))) return -EINVAL; if (flags & GRND_TRUERANDOM) { ... do the TRNG processing ... ... may return -ENOPNOTSUPP if no TRNG available ... } Thanks a lot. Ciao Stephan