Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp2501618ybe; Sat, 14 Sep 2019 16:45:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqx62kV4PqRHVwSA4h7wr5+bwi5Mf9ffVLGtDWl9C5VCnhtLpTQF4U2OtLfhj0pK3DH3kzDO X-Received: by 2002:a17:906:5e09:: with SMTP id n9mr36497703eju.143.1568504749502; Sat, 14 Sep 2019 16:45:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568504749; cv=none; d=google.com; s=arc-20160816; b=MeZiCH23D1IHUJjx3sj6lmimrSGTBfyhQMTU9821iiFE9JucOGlO3rECJEfcQgOf2Y BI7DSCbeZMpC1hO9wRSqQcHk8azMvqmDOfEWNLRJu+2ocyF5brjpXKK1+6q+7aN/Ai91 dAtXILUEuwo06iSFf5jCD6IlrVw0GfJkg/hvrVR0SykkTC/edfUvqwF7LKQo0dK9Pi/W ezTK2jzCynfbTZ+GU+m1VEnxfbLSbx9FlsgkB44kYd9q9aWWDKe8Cscpe4wswz/DxCBG h9effi9T05XlA4/LNYBXiKdC4sjD91IC3YJBDUx/CSPflnMP7734/Fso7Xroe+CNyY2p kYOQ== 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=mVrs98EExiMzmaB8/nArfJLjYfNARudESXTuoWUTmQ8=; b=jbYHBO+bMvkfjZWhPeS1+x8Gdf34iIoS5AGgLNjbUi5It0ORGVoYTs4IhnyNTCMqhe FdyIHewJEmT30Ur50v4H1OtGpFMaC7gCYIJUUtZj27x8rGZFTYNbivgkrJMx5dXO2WKO p8DHc/4QkAyGIgmkniDVk6Qa52e25VClAWaso+XXt8QNS52VVQIll9QO2z1oowjLvSNs FHYkhqi3q9LoBb0yOztYPyfV64UIxcMNAFWfN0CUqa3DpqsoT2uR78tAME4cYKwBiXLU hEue3TZhe/sBXF8R1BC/+9KzPU1pWDjlsfGYgBh7d89fJZfOsYQB7PAf/Y+eObFVPfmo XdxA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-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 j12si17800484edn.348.2019.09.14.16.45.24; Sat, 14 Sep 2019 16:45:49 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-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-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727587AbfINWZA (ORCPT + 99 others); Sat, 14 Sep 2019 18:25:00 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:39962 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727584AbfINWY7 (ORCPT ); Sat, 14 Sep 2019 18:24:59 -0400 Received: from callcc.thunk.org ([66.31.38.53]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8EMOWFO000980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 14 Sep 2019 18:24:33 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 843CB42049E; Sat, 14 Sep 2019 18:24:32 -0400 (EDT) Date: Sat, 14 Sep 2019 18:24:32 -0400 From: "Theodore Y. Ts'o" To: "Ahmed S. Darwish" Cc: Linus Torvalds , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, Lennart Poettering , lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190914222432.GC19710@mit.edu> References: <20190911160729.GF2740@mit.edu> <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <20190914211126.GA4355@darwi-home-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190914211126.GA4355@darwi-home-pc> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Sat, Sep 14, 2019 at 11:11:26PM +0200, Ahmed S. Darwish wrote: > > > I've sent an RFC patch at [1]. > > > > > > [1] https://lkml.kernel.org/r/20190914122500.GA1425@darwi-home-pc > > > > Looks reasonable to me. Except I'd just make it simpler and make it a > > big WARN_ON_ONCE(), which is a lot harder to miss than pr_notice(). > > Make it clear that it is a *bug* if user space thinks it should wait > > at boot time. So I'd really rather not make a change as fundamental as this so close to 5.3 being released. This sort of thing is subtle since essentially what we're trying to do is to work around broken userspace, and worse, in many cases, obstinent, determined userspace application progammers. We've told them to avoid trying to generate cryptographically secure random numbers for *years*. And they haven't listened. This is also a fairly major functional change which is likely to be very visible to userspace applications, and so it is likely to cause *some* kind of breakage. So if/when this breaks applications, are we going to then have to revert it? > > Also, we might even want to just fill the buffer and return 0 at that > > point, to make sure that even more broken user space doesn't then try > > to sleep manually and turn it into a "I'll wait myself" loop. Ugh. This makes getrandom(2) unreliable for application programers, in that it returns success, but with the buffer filled with something which is definitely not random. Please, let's not. Worse, it won't even accomplish something against an obstinant programmers. Someone who is going to change their program to sleep loop waiting for getrandom(2) to not return with an error can just as easily check for a buffer which is zero-filled, or an unchanged buffer, and then sleep loop on that. Again, remember we're trying to work around malicious human beings --- except instead trying to fight malicious attackers, we're trying to fight malicious userspace programmers. This is not a fight we can win. We can't make getrandom(2) idiot-proof, because idiots are too d*mned ingenious :-) For 5.3, can we please consider my proposal in [1]? [1] https://lore.kernel.org/linux-ext4/20190914162719.GA19710@mit.edu/ We can try to discuss different ways of working around broken/stupid userspace, but let's wait until after the LTS release, and ultimately, I still think we need to just try to get more randomness from hardware whichever way we can. Pretty much all x86 laptop/desktop have TPM's. So let's use that, in combination with RDRAND, and UEFI provided randomness, etc., etc., And if we want to put in a big WARN_ON_ONCE, sure. But we've tried not blocking before, and that way didn't end well[2], with almost 10% of all publically accessible SSH keys across the entire internet being shown to be week by an academic researcher. (This ruined my July 4th holidays in 2012 when I was working on patches to fix this on very short notice.) So let's *please* not be hasty with changes here. We're dealing with a complex systems that includes some very obstinent/strong personalities, including one which rhymes with Loettering.... [2] https://factorable.net - Ted