Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5114226ybe; Tue, 17 Sep 2019 02:53:10 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLJp1qX8FJdlAuib+thvebsoHvCzHaX1QshO+DEzGjYgb2IU1rQ+fjZuGCho5R/A5iI72V X-Received: by 2002:a17:907:2124:: with SMTP id qo4mr3737068ejb.311.1568713990669; Tue, 17 Sep 2019 02:53:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568713990; cv=none; d=google.com; s=arc-20160816; b=dKQSthh3enU2lxlUptQNgmCrqfq6fRIX6qv04UeNKvvHHtmwZbXNBhcDUb+bAbxCHE h3m/q9Paf+0b5Bs4Z8TEHRB+g8I3a1BGRi7vjLWtWlYo2Vo7sFJnbNV7nNXEe+q766+D +oIQLgP6qMp1/pSoWFP92kz2CXlfe4eyG+l+o9wPI8+JqZjkaS7kxtY0K6u1JzV3ABnw AlNo6BUrjw9kC7bzYJhyz69+tsbDzNvgXs7zL7VAvgKo+fNLcjrEkN7LiH/IbvhnYeyJ Tbfbc2fDr7iQJmvd9E98aLe0YPw3TIuW9Gn934feFQKYPk56a0N9rYenqn2qZCsbwJVb u3SA== 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=eWEuTEbbi849pfrxUcjrZXFZOJ/Kjk5FUAZfQWEzGg8=; b=ajzw87+pUXU1YaVB/R1GQ04lNJXQGzJ90ApPaHmuQs2JrKxbv0VMO46w6yh5Kn+r7I 0VskrvA40AHMKYSiMw5A2cVIGOa0xQ9cjnrsglIImJAmw7ZoWBzieFKzN3yRSiwxCeyz ASGQHNlmhcgpR441jP2+Zl9bvm31A2UdDizsT8oUFtcxjhUndUxhYyWlM4B27Y+Zspbr ajqgg2zYmbfb6EzeW2qDC+CbCJLcrQDezoAvAZdl3nwcl3SccjsjXOUqThR/0PO5GaVP VGuw5Wn9M2KPKs/cl2Cr6yTi+Kk1kQIJesDVCA9Ms+QXQbjbbkzI1XJH9faIY50bmXau yJiw== 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 h64si1059125edd.196.2019.09.17.02.52.46; Tue, 17 Sep 2019 02:53:10 -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 S2388221AbfIQIfz (ORCPT + 99 others); Tue, 17 Sep 2019 04:35:55 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:46740 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387967AbfIQIfy (ORCPT ); Tue, 17 Sep 2019 04:35:54 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8H8ZGKL027108; Tue, 17 Sep 2019 10:35:16 +0200 Date: Tue, 17 Sep 2019 10:35:16 +0200 From: Willy Tarreau To: Martin Steigerwald Cc: Matthew Garrett , Linus Torvalds , "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Vito Caputo , 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: <20190917083516.GA27098@1wt.eu> References: <20190917052438.GA26923@1wt.eu> <2508489.jOnZlRuxVn@merkaba> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2508489.jOnZlRuxVn@merkaba> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Tue, Sep 17, 2019 at 09:33:40AM +0200, Martin Steigerwald wrote: > However this again would be burdening users with an issue they should > not have to care about. Unless userspace developers care enough and > manage to take time to fix the issue before updated kernels come to their > systems. Cause again it would be users systems that would not be > working. Just cause kernel and userspace developers did not agree and > chose to fight with each other instead of talking *with* each other. It has nothing to do with fighting at all, it has to do with offering what applications *need* without breaking existing assumptions that make most applications work. And more importantly it involves not silently breaking applications which need good randomness for long lived keys because the breakage will not be visible initially and can hit them hard later. Right now most applications which block in the early stages are only victim of the current situation and their developers possibly didn't understand the possible impacts of lack of entropy (or how real an issue it was). These applications do need to be able to get low-quality random without blocking forever, provided these are not accidently used by those who need security. At some point, just like for any syscall, the doc makes the difference. > At least with killing gdm Systemd may restart it if configured to do so. > But if it doesn't, the user is again stuck with a non working system > until restarting gdm themselves. > > It may still make sense to make the API harder to use, No. What is hard to use is often misused. It must be harder to misuse it, which means it should be easier to correctly use it. The choice of flag names and the emission of warnings definitely helps during the development stage. > but it does not > replace talking with userspace developers and it would need some time to > allow for adapting userspace applications and services. Which is how adding new flags can definitely help even if adoption takes time. By the way in this discussion I am a userspace developer and have been hit several times by libraries switching to getrandom() that silently failed to respond in field. As a userspace developer, I really want to see a solution to this problem. And I'm fine if the kernel decides to kill haproxy for using getrandom() with the old settings, at least users will notice, will complain to me and will update. Willy