Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp6446781ybn; Sun, 29 Sep 2019 20:39:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqypcN6FA8Bo8hCQB8wTkfKkYU8XI2uotN8UaEZ2p/nkphASS6y7n2n9Q8Fg22k4eAnV7K/S X-Received: by 2002:a05:6402:14d0:: with SMTP id f16mr17355636edx.41.1569814760599; Sun, 29 Sep 2019 20:39:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569814760; cv=none; d=google.com; s=arc-20160816; b=LJtmS3nXhz4KrIjnzDxqojkKLoVqCkIrrpbQdmTlCG4cIg1u2Ce50wq/7FDUfxFL5C auwQ9NG1GQfxsVNVrJZf8V/tmT+ksBjIZesNhlwMZofIX+juF30iZ1f7jbFo2t3HDH+d sAepd/ksivP4RQFlZCnsi/lBSUH5NrKKeo/PtOOxwI036y/Mc6EyFH8m7pVvT7nHRMSH sCPM2X5lcoD6QA+YdBOLpDlxfqBM3uXRrsOJRGnnz8lOIc7S4kcGGfWVM93ZNjvMdRny fnuibvCzKe1iZkvpYXwMid9aKZ2CXdw7Uu7INAox2IYDxhxu6Yd1qy/Mp9tvd7YgcDL6 Lrnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=sn978bRa4sEaOxrjavLxpGh6PDfAjxQOAXVEV0KdMUs=; b=Z97MFj+ed34wvRw7agW5RqD4KjnHy5ssxm9lId/mF9bYJ/ZYnXDA7PlWEAzkVQrHcG PcHhZkVvc0POV5C5xTwdz0Gty/jTcq/JYngUZxdyXMa3F9xXbf+9ErKX4XSJzfzfvOzL UMTtqVhWHePGMcgZCVotk7DwJvpqcPT5prbhYQ8Oofya1Zo0fGrIfxe+LX5gGUIAr4Gb C8OXHCLvElpDhXHjGfXcjYTax+oKvCvHAeMwYgETaMZc1FEkQBg6BxjKuCG37yk82lRR M4LGRFD+b4N/PNnqDzx7r9tODB9LqIbtsnRkclx5fa96dWwU76W3smGZw3yueyTzmg6J i3VQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 y47si6108125edd.236.2019.09.29.20.38.56; Sun, 29 Sep 2019 20:39:20 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729507AbfI3Dhi (ORCPT + 99 others); Sun, 29 Sep 2019 23:37:38 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:39508 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728853AbfI3Dhh (ORCPT ); Sun, 29 Sep 2019 23:37:37 -0400 Received: from callcc.thunk.org (pool-72-93-95-157.bstnma.fios.verizon.net [72.93.95.157]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8U3b6k9005328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 29 Sep 2019 23:37:07 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id C158C42014C; Sun, 29 Sep 2019 23:37:06 -0400 (EDT) Date: Sun, 29 Sep 2019 23:37:06 -0400 From: "Theodore Y. Ts'o" To: Linus Torvalds Cc: Thomas Gleixner , "Ahmed S. Darwish" , LKML , Nicholas Mc Guire , the arch/x86 maintainers , Andy Lutomirski , Kees Cook Subject: Re: x86/random: Speculation to the rescue Message-ID: <20190930033706.GD4994@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 29, 2019 at 06:16:33PM -0700, Linus Torvalds wrote: > > - or just say "hey, a lot of people find jitter entropy reasonable, > so let's just try this". > I'm OK with this as a starting point. If a jitter entropy system allow us to get pass this logjam, let's do it. At least for the x86 architecture, it will be security through obscurity. And if the alternative is potentially failing where the adversary can attack the CRNG, it's my preference. It's certainly better than nothing. That being said, I'd very much like to see someone do an analysis of how well these jitter schemes work on an RISC-V iplementation (you know, the ones that were so simplistic and didn't have any speculation so they weren't vulnerable to Specture/Meltdown). If jitter approaches turn out not to work that well on RISC-V, perhaps that will be a goad for future RISC-V chips to include the crypto extension to their ISA. In the long term (not in time for the 5.4 merge window), I'm convinced that we should be trying as many ways of getting entropy as possible. If we're using UEFI, we should be trying to get it from UEFI's secure random number generator; if there is a TPM, we should be trying to get random numbers from the RPM, and mix them in, and so on. After all, the reason why lived with getrandom(0) blocking for five years was because for the vast majority of x86 platforms, it simply wasn't problem in practice. We need to get back to that place where in practice, we've harvested as much uncertainty from hardware as possible, so most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security. - Ted