Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp3603215ybe; Sun, 15 Sep 2019 20:01:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqwH6n18vPGa/6Unv+shNSoRv9y5AO2e44BYVaIyd1y7UTLAYQB1j4biBml7wtHw94kU6Eii X-Received: by 2002:a50:fa83:: with SMTP id w3mr3635049edr.262.1568602867094; Sun, 15 Sep 2019 20:01:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568602867; cv=none; d=google.com; s=arc-20160816; b=H7wFnnXqqhiyrfdsKLQcG3TrweOGmXUhmIKBccwirH9OYKbA3mmlYkEIlmVaueRgMD 4BPYiqwx79eJINSmw+ALO8pfgCS7YpPwaN+j0EovF1HyT3XX3qMEiUZaIuMr+ws+nMy2 AgeDApW+n88at0/KuU7JJpZIvSUdaLqfRHfgI5crYteWSz9tEWnGJGB+JSSDLUT21bAa eB4NQmKbbESUkrMm0a3cZrPb5vpTQ5UgtFwLqzGf1xRVcLfInOQ8ENbAW4z/4+Z9yexA i9LMf6v25EvD9CrJR5DzHmlaGVlOqBP/BK2Zm2euiJ0oo1aH/mwZPuIZDEZOmEU4UPGY 9rmA== 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=VvcA6vn6LnrZA8G6YSIAI/SUcWpAPS3erjXWTb3TXZg=; b=MpR8Xg/EYfxWE5XNN11awkb3c+fEEMD8taArJPzYEqHOdxKDptg2fC8UcsxqFJXB6C obgqkrXRaKwdrXOfR1dlLis77TvFo0M58ntHO/p0jK2QdM71huO1FzdWj3muc7l6XwUh nJpS1l42caqo7AIoLlzBgNtFIjxNMil2SRsLHxZvfE62VG6u2UDfPYdskXqQHAeB8ZiT vend409ktY48DG/hnfoZ7HacKKIHD71i69VcrFGgIGFl5Wcu7mC2PAjwXm5WykPCvKyr NqSTs/snZSYqbKXEP7GjQBIw9psIaV8R0ZByuwf025OUNoEXcuQtHHeFjlujUGstqC6S fpxg== 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 o22si1763436ejb.285.2019.09.15.20.00.43; Sun, 15 Sep 2019 20:01:07 -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 S1725866AbfIPCth (ORCPT + 99 others); Sun, 15 Sep 2019 22:49:37 -0400 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:36611 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727373AbfIPCth (ORCPT ); Sun, 15 Sep 2019 22:49: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 x8G2n5mh000962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Sep 2019 22:49:06 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id A349E420811; Sun, 15 Sep 2019 22:49:04 -0400 (EDT) Date: Sun, 15 Sep 2019 22:49:04 -0400 From: "Theodore Y. Ts'o" To: Vito Caputo Cc: "Ahmed S. Darwish" , Linus Torvalds , Lennart Poettering , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190916024904.GA22035@mit.edu> References: <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <20190915065142.GA29681@gardel-login> <20190916014050.GA7002@darwi-home-pc> <20190916014833.cbetw4sqm3lq4x6m@shells.gnugeneration.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190916014833.cbetw4sqm3lq4x6m@shells.gnugeneration.com> 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 Sun, Sep 15, 2019 at 06:48:34PM -0700, Vito Caputo wrote: > > A small note here, especially after I've just read the commit log of > > 72dbcf721566 ('Revert ext4: "make __ext4_get_inode_loc plug"'), which > > unfairly blames systemd there. ... > > What blocked the system boot was GDM/gnome-session implicitly calling > > getrandom() for the Xorg MIT cookie. This was shown in the strace log > > below: > > > > https://lkml.kernel.org/r/20190910173243.GA3992@darwi-home-pc Yes, that's correct, this isn't really systemd's fault. It's a combination of GDM/gnome-session stupidly using MIT Magic Cookie at *all* (it was a bad idea 30 years ago, and it's a bad idea in 2019), GDM/gnome-session using getrandom(2) at all; it should have just stuck with /dev/urandom, or heck just used random_r(3) since when we're talking about MIT Magic Cookie, there's no real security *anyway*. It's also a combination of the hardware used by this particular user, the init scripts in use that were probably not generating enough read requests compared to other distributions (ironically, distributions and init systems that try the hardest to accelerate the boot make this problem worse by reducing the entropy that can be harvested from I/O). And then when we optimzied ext4 so it would be more efficient, that tipped this particular user over the edge. Linus might not have liked my proposal to disable the optimization if the CRNG isn't optimized, but ultimately this problem *has* gotten worse because we've optimized things more. So to the extent that systemd has made systems boot faster, you could call that systemd's "fault" --- just as Linus reverting ext4's performance optimization is ssaying that it's ext4 "fault" because we had the temerity to try to make the file system be more efficient, and hence, reduce entropy that can be collected. Ultimately, though, the person who touches this last is whose "fault" it is. And the problem is because it really is a no-win situation here. No matter *what* we do, it's going to either (a) make some systems insecure, or (b) make some systems more likely hang while booting. Whether you consider the risk of (a) or (b) to be worse is ultimately going to cause you to say that people of the contrary opinion are either "being reckless with system security", or "incompetent at system design". And really, it's all going to depend on how the Linux kernel is being used. The fact that Linux is being used in IOT devices, mobile handsets, desktops, servers running in VM's, user desktops, etc., means that there will be some situations where blocking is going to be terrible, and some situations where a failure to provide system security could result in risking someone's life, health, or mission failure in some critical system. That's why this discussion can easily get toxic. If you are only focusing on one part of Linux market, then obviously *you* are the only sane one, and everyone *else* who disagrees with you must be incompetent. When, perhaps, they may simply be focusing on a different part of the ecosystem where Linux is used. > So did systemd-random-seed instead drain what little entropy there was > before GDM started, increasing the likelihood a subsequent getrandom() > call would block? No. Getrandom(2) uses the new CRNG, which is either initialized, or it's not. Once it's initialized, it won't block again ever. - Ted