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.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 DE8ABC432C0 for ; Sun, 24 Nov 2019 04:51:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B4FFA20830 for ; Sun, 24 Nov 2019 04:51:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="cqqaBO8r" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726803AbfKXEvg (ORCPT ); Sat, 23 Nov 2019 23:51:36 -0500 Received: from mail-wr1-f67.google.com ([209.85.221.67]:33820 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726705AbfKXEvg (ORCPT ); Sat, 23 Nov 2019 23:51:36 -0500 Received: by mail-wr1-f67.google.com with SMTP id t2so13415832wrr.1; Sat, 23 Nov 2019 20:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UMNvMZ2fiueHFeBLtH1yqoxzy6gBcmr82O5GZYCic0I=; b=cqqaBO8rwLZCQAQHTXvCo2RUBKkg8tdFoISyP22RXsT8TTixtNpakZvXcy6Yd/mQIX sSt4Wd4DXjh34IK6EX00eNiCIJhjF4YyFXVyOMgNzWIRzt4rIUqz0ibinZKsOOU2Bd+k MqZ8DJcC7B2lXlns95IdHGkfWSuBxOzflkmFJziQvDK0lwAHvJmnWrp1lLnFzogIQmUf P83uCcRySIPT4G9dAx3Xs9RzwvIUC/QOfgczueCPmJmjkMTTOMaXckNXxRjF+Gp2tVjh fNPFNNp+vUugcdWyBf/a9ZZur8HzS5F44nlHVKsxTq+lo+gLLQr3EkumPuLgTtt2JTmv ffKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=UMNvMZ2fiueHFeBLtH1yqoxzy6gBcmr82O5GZYCic0I=; b=m8w8bieCVaPa2snwVztCmToLo9S7mK3mCXywWBtlpIU//INUSVcawK/Scp3G+fzQOJ MDB9Z2rzHTxz2qRMtakzDC0SF/nMnYmlbNVxNXj2H+ZVMVx/jckhIbIG4FeS63yUP3Ty aOcbSEeilsuYcZeMBordWb4HrveBaoRt5xDhPi+aWUaiOBObM+eifYbHSQRjfozuAE3d 86gTm1q9GaD/QnWnxwKx2Wo8Jn5YWCLq6GaPld1xCa4R5AAs9yyDAMDNm6H++VC4mLh1 nJ4Jdeth6iNHGhWc0CnnkhetBVJ7S6vYA+v47YLP+7ELJIVIY/5zTlxojc3PFtJtwz4z cWLw== X-Gm-Message-State: APjAAAWZ7CCbdmvcYnpR0kAZ2gXa1R9FmuEVnOaLmxN9RavepJDGfBar sWXE7LjHXhlVfErlykRM9Vl950KnFOfN1acVuBQ= X-Google-Smtp-Source: APXvYqzbmBMaUZ7OFJ0tend1/u7Cs6qVFDD/rGCvqIMqwRuT0rDHfIou/pqOPQldrOCGd5rCi9+hdcY/eGpacKVnWhE= X-Received: by 2002:adf:ea8d:: with SMTP id s13mr24873434wrm.366.1574571093582; Sat, 23 Nov 2019 20:51:33 -0800 (PST) MIME-Version: 1.0 References: <6157374.ptSnyUpaCn@positron.chronox.de> <2369119.jSEA3qhmGI@positron.chronox.de> In-Reply-To: <2369119.jSEA3qhmGI@positron.chronox.de> From: Sandy Harris Date: Sun, 24 Nov 2019 12:51:19 +0800 Message-ID: Subject: Re: [PATCH v24 01/12] Linux Random Number Generator To: =?UTF-8?Q?Stephan_M=C3=BCller?= Cc: Arnd Bergmann , Greg Kroah-Hartman , Linux Crypto Mailing List , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Stephan M=C3=BCller wrote: > In an effort to provide a flexible implementation for a random number > generator that also ... As usual, some of your proposals make considerable sense to me & others do not, at least on first reading. I may have more comments after reflecting some. Meanwhile, a couple of things jump out at me: > (a) When an interrupt occurs, the high-resolution time stamp is mixed > into the LFSR. ... > > (b) HID event data like the key stroke or the mouse coordinates are > mixed into the LFSR. ... > > (c) Device drivers may provide data that is mixed into the LFSR. ... Why into the LFSR instead of into the entropy pool? > The LRNG allows the TRNG and secondary DRNG mechanism to be changed > at runtime. Why? This strikes me as pointless complication. > * high performance of interrupt handling code: The LRNG impact on the > interrupt handling has been reduced to a minimum. On one example > system, the LRNG interrupt handling code executes within an average > of 65 cycles whereas the existing /dev/random on the same device > takes about 97 cycles when measuring the execution time of > add_interrupt_randomness(). Assuming you do this without sacrificing the input mixing, this would be worth submitting as a separate patch. Saving cycles on every interrupt definitely looks worth doing. > * lockless LFSR to collect raw entropy This too.