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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, 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 1E34CC2D0CE for ; Sun, 29 Dec 2019 15:09:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E9BA4207FD for ; Sun, 29 Dec 2019 15:08:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="S+uZxX+E" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726653AbfL2PIz (ORCPT ); Sun, 29 Dec 2019 10:08:55 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:33095 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726189AbfL2PIz (ORCPT ); Sun, 29 Dec 2019 10:08:55 -0500 Received: by mail-oi1-f195.google.com with SMTP id v140so10563794oie.0 for ; Sun, 29 Dec 2019 07:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=JpqRu20LZHxdWN1UW9AkuUQvQXkCetz6nWnrVXZaXRg=; b=S+uZxX+EaQmPyB6zJ2fqU/hUZuwlpmMS4Hu3op3yUKzfg+ck49mpuWaMrCl8Ro03Sf P05YwiT9hWqZYAfCCPEX/l/A8d5Fay2EEpm05+o4kmdiBfoEXLTD88+5f/1LLws9AsN+ nYHetUMmzMlUs+pTTZ+yL/MCwEHdNtXJ0AjyriI6S2AWH91p4gMxlmiILlQscp4l5bZP tkmzsKjJd/j+6FFjOYdh2mz4cu9GyxzT7vp8Scpt+up6IoUN2jTI5FKBH1OyxHyM7U56 9gMqeHWsAx7qlHry2TcgBE5OUIKF7xYIP7qIHkbtrVOCZgz1eZlnSJt0mat7uv7604if SXLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=JpqRu20LZHxdWN1UW9AkuUQvQXkCetz6nWnrVXZaXRg=; b=YW5XNuUjWdIqgLOXx8oaAJ/GXFW0SeB1Q1TBKjBn440gfrqG1KRgTwWSIms/S3kMkY CYMhTE1ksS/quM3AqbDiQsdghmm+E+y25Xi33Ae1nGi792UJysiKRb9N/242jHPrXoVH NXmajX+OKCVX/0cohmHnUlK4B4I7HapMb2btorOyKd1p9xJjdh+b8ztg0cKO4zzKu91K ZSdT+Pr4U61EIlLMOZRYryQnE5NY9hFYFFxOUhwmWEcFs+RP3zue8cGbNpc4L2OZMDkx gAbFSlPYtI+bG6E/DDtRgeKoOKOrAPqxXKH4422U7KiVjZqMV5J5jeiWIp/7pSaBvUs5 NeTg== X-Gm-Message-State: APjAAAXPMMKdHEqExHxf3Mv0MDru+067vohTev2Ho5Q3xsYHT/9f/kH2 EmM7IzidWm5uPIeAA6IMdCUJpQ== X-Google-Smtp-Source: APXvYqxjo/qRxZba1IgLCKplUt2/vIzbNAMP97x3QWuUCy1ztu/OkNu7bZ2vnDIB9uXXfpGv2kA/vQ== X-Received: by 2002:aca:758a:: with SMTP id q132mr5236846oic.162.1577632134837; Sun, 29 Dec 2019 07:08:54 -0800 (PST) Received: from [26.83.181.6] ([172.58.107.236]) by smtp.gmail.com with ESMTPSA id t25sm12835238oij.17.2019.12.29.07.08.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 29 Dec 2019 07:08:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v3 0/8] Rework random blocking Date: Sun, 29 Dec 2019 23:08:50 +0800 Message-Id: References: <20191229144904.GB7177@mit.edu> Cc: Andy Lutomirski , Stephan Mueller , LKML , Linux API , Kees Cook , "Jason A. Donenfeld" , "Ahmed S. Darwish" , Lennart Poettering , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Willy Tarreau , Matthew Garrett , Ext4 Developers List , linux-man In-Reply-To: <20191229144904.GB7177@mit.edu> To: "Theodore Y. Ts'o" X-Mailer: iPhone Mail (17C54) Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org > On Dec 29, 2019, at 10:49 PM, Theodore Y. Ts'o wrote: >=20 > =EF=BB=BFOn Fri, Dec 27, 2019 at 06:06:56PM -0800, Andy Lutomirski wrote: >>=20 >> I'm thinking of having a real class device and chardev for each hwrng >> device. Authentication is entirely in userspace: whatever user code >> is involved can look at the sysfs hierarchy and decide to what extent >> it trusts a given source. This could be done based on bus topology or >> based on anything else. >=20 > Yes, that's what I was thinking. Another project on my "when I can > get a round tuit" list is to change how drivers/char/random.c taps > into the hwrng devices, mixing in a bit from each of these devies in a > round-robin fashion, instead of just feeding from a single hwrng. >=20 >> The kernel could also separately expose various noise sources, and the >> user code can do whatever it wants with them. But these should be >> explicitly unconditioned, un-entropy-extracted sources -- user code >> can run its favorite algorithm to extract something it believes to be >> useful. The only conceptually tricky bit is keeping user code like >> this from interfering with the in-kernel RNG. >=20 > The other problem is the unconditioned values of the noise sources may > leak unacceptable amounts of information about system operation. The > most obvious example of this would be keyboard and mouse sources, > where today we mix in not only the timing information, but the actual > input values (e.g., the keyboard scancodes) into the entropy pool. > Exposing this to userspace, even if it is via a privileged system > call, would be... unwise. >=20 > =20 Hmm. We could give only the timing. We could also say that the official interface for this is to use tracepoints= and punt everything into userspace.=