Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp6940525ybn; Mon, 30 Sep 2019 06:17:56 -0700 (PDT) X-Google-Smtp-Source: APXvYqwz0XO9tMTdLXdPan97+dv02kkj3EYIJe4m3MHcL5W192vqCzVfHqrXE8qcATaQ1mSchFLR X-Received: by 2002:a17:906:e0d1:: with SMTP id gl17mr18563021ejb.99.1569849476511; Mon, 30 Sep 2019 06:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569849476; cv=none; d=google.com; s=arc-20160816; b=WSPZthsCLfmjWo2KOvRgzWlZdJgll2XVrrUpXEQTeMZdXlCAbuToMsRRFCGVfaXgBf vL0SewT0fI6t3MRIRbpNpa99XfyWH+YZs53AhytAiyxkJFsWW0fKEgtG0WSkpdGyD1Kx pixZtnZYFae9CfAhV1tUsHUtYN7BMdKX5jO7KGd7CNZWo//7/TnKjttSGiTDIjI9SLbT YS7ch4Lzs9FyCgdUuhXofT0iF7axMJGuRFUeTBcd+KMJlzXVGKssNuGrQqWMG5KESJJ2 oIg8yzHUoWVmjJPAwa0F4Yf8cHbXhIgo01Act83J9M3FsCEx9dfBSSBPgsIcm20PCbcm vSnA== 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=iVMPxmYJ1mKr8tnjOWDQ8wrpvo79ByzFxGkZkIwyLfk=; b=gOFcz6sQRAwffB0kBcpPuycIotSELvSvXpHf5dVUpIWy/yWi+53HyTHqc9Mj/y8p5t hUUhCaybmRxloFi9OzsMHkXoxqoBuuzpouSYDleOYCAFtrpH+ugG9uTAbbKfAmoV6jpm i1SNveJRa3x6L8Y6TZNPMnivPwFBcY/Vy+cKG+YWTq5W08h4qF1gUjt3YS01098FDT85 Uufxd3ceQIn4BgRhVOWLgAoWFq+7Gf3S6RckrtHVcT/bAWx093ZtChOIKaAvstW7n/CT BA1zyObn/xrCpd8cpGLtIY48hr5HH2OvcD3dL6gWljEc0iHT2rLYg6ZBdicQFeGOmfRM jqdA== 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 oa24si6817004ejb.41.2019.09.30.06.17.32; Mon, 30 Sep 2019 06:17:56 -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 S1730929AbfI3NRI (ORCPT + 99 others); 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