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=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 637FAC32792 for ; Mon, 30 Sep 2019 13:17:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 35F4220842 for ; Mon, 30 Sep 2019 13:17:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731047AbfI3NRI (ORCPT ); Mon, 30 Sep 2019 09:17:08 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:46250 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726314AbfI3NRI (ORCPT ); Mon, 30 Sep 2019 09:17:08 -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 x8UDGd9A010000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Sep 2019 09:16:39 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 1C89142014C; Mon, 30 Sep 2019 09:16:39 -0400 (EDT) Date: Mon, 30 Sep 2019 09:16:39 -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: <20190930131639.GF4994@mit.edu> References: <20190930033706.GD4994@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190930033706.GD4994@mit.edu> 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 11:37:06PM -0400, Theodore Y. Ts'o wrote: > 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. Upon rereading this, this came out wrong. What I was trying to say is in the very worst case, it will be security through obscurity, and if the alternative "don't block, because blocking is always worse than an guessable value being returned through getrandom(0)", it's better than nothing. Which is to say, I'm still worried that people with deep access to the implementation details of a CPU might be able to reverse engineer what a jitter entropy scheme produces. This is why I'd be curious to see the results when someone tries to attack a jitter scheme on a fully open, simple architecture such as RISC-V. - Ted