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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 190E9C433EF for ; Wed, 30 Mar 2022 19:02:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346534AbiC3TDp (ORCPT ); Wed, 30 Mar 2022 15:03:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350394AbiC3TDk (ORCPT ); Wed, 30 Mar 2022 15:03:40 -0400 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 577FD7B543; Wed, 30 Mar 2022 12:01:54 -0700 (PDT) Received: from callcc.thunk.org (c-24-1-67-28.hsd1.il.comcast.net [24.1.67.28]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22UJ1V8e008101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Mar 2022 15:01:32 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 73D894200DE; Wed, 30 Mar 2022 15:01:31 -0400 (EDT) Date: Wed, 30 Mar 2022 15:01:31 -0400 From: "Theodore Y. Ts'o" To: Michael Brooks Cc: David Laight , Sasha Levin , Dominik Brodowski , Eric Biggers , Greg Kroah-Hartman , "Jason A. Donenfeld" , Jean-Philippe Aumasson , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Subject: Re: [PATCH AUTOSEL 5.17 16/43] random: use computational hash for entropy extraction Message-ID: References: <20220328111828.1554086-1-sashal@kernel.org> <20220328111828.1554086-16-sashal@kernel.org> <9e78091d07d74550b591c6a594cd72cc@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 30, 2022 at 11:33:21AM -0700, Michael Brooks wrote: > The /dev/random device driver need not concern itself with root > adversaries as this type of user has permissions to read and overwrite > memory - this user even possesses permission to replace the kernel elf > binary with a copy of /dev/random that always returns the number 0 - > that is their right. The design consideration that random number generators do concern themselves with is recovery after pool exposure. This could happen through any number of ways; maybe someone got a hold of the suspended image after a hiberation, or maybe a VM is getting hybernated, and then replicated, etc. One can argue whether or not it's "reasonable" that these sorts of attacks could happen, or whether they are equivalent to full root access whether you can overwrite the pool. The point remains that it is *possible* to have situations where the internal state of the RNG might have gotten exposed, and a design criteria is how quickly or reliably can you reocver from that situation over time. See the Yarrow paper and its discussion of iterative guessing attack for an explanation of why cryptographers like John Kelsey, Bruce Schneier, and Niels Ferguson think it is important. And please don't argue with me on this point while discussing which patches should be backported to stable kernels --- argue with them. :-) Cheers, - Ted