Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5106109ybe; Tue, 17 Sep 2019 02:43:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzR6IAOrF4m4vQ/E+/UibqdrikDlOINYFk3YrhwWhPFdZCmMh5H9ek0C+S7HnFlhQUBpF9Y X-Received: by 2002:a17:906:3294:: with SMTP id 20mr3813328ejw.19.1568713387617; Tue, 17 Sep 2019 02:43:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568713387; cv=none; d=google.com; s=arc-20160816; b=UtYhuSez0bfhhKftlyIpP2zOOgcXocXHH/DQYlnXiG1grro2M5ZlILHeRyyhTad2ZC EGQyxUGwyOk3k/15egtioMloOoo/U4+FCazAkKXMA3s6A1RAmAmIQElmL+vXjUsWHFUF QsOqGrJ58Q5NALHDS1yR9LbcmYJTO4oPQ6QMnZnQW7KkqcqpJfbQA6Pwna5HHK3cmPa+ PTjcQzmolfLBa7WHV2FbwUBgc8qNeYbmnNGNeRpUyhOhW5g+UiDGKf+qQbJUXs62obXu +cGblP4SERkES18bSFpTFeg2EFsV6Gq0LjQm9Wc5/N2cB+ipEOeio8fRHgLWIOh9NEIA 8ICw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=ZHZEKq2BDjajRz1moGT58QCUUo7QKyvt1MLdr1/lDy4=; b=AnRaMp8GgJQ+UdFha/qBj6dQAlmiJdHV3dqtD1wuMD7mfQUhtniGH0Bu/w2zfFgZpd XYOKMzrKZo44oxj78oc1xm5OBFBrs91m4kgnFxCY3YicyrU0sbqz2m9BfmqP8cKLrq2h 2fcCn68TV0YsX0XD54jUJnkvOoqT2TPVdiorjv5RzTJUH1prRUId8pV7a86UDHkE2nrZ m2BJ4zQYGI+hImAT3GIucpv2hj/6YSB8oQOZDYuL446eaV8Zmk5Ydk7dhTLnUk+KqbBN pzJycXL121bk+CdpWdfc/on6QgaV2l6QP00wvthM86VnVkeeGuwIKoWdXq7RSp5q9M19 HtsA== 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 y9si977839edp.305.2019.09.17.02.42.43; Tue, 17 Sep 2019 02:43: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 S2404466AbfIQHdn (ORCPT + 99 others); Tue, 17 Sep 2019 03:33:43 -0400 Received: from luna.lichtvoll.de ([194.150.191.11]:48487 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2404465AbfIQHdn (ORCPT ); Tue, 17 Sep 2019 03:33:43 -0400 Received: from 127.0.0.1 (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.lichtvoll.de (Postfix) with ESMTPSA id BA1FB772DF; Tue, 17 Sep 2019 09:33:40 +0200 (CEST) From: Martin Steigerwald To: Willy Tarreau 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 Date: Tue, 17 Sep 2019 09:33:40 +0200 Message-ID: <2508489.jOnZlRuxVn@merkaba> In-Reply-To: <20190917052438.GA26923@1wt.eu> References: <20190917052438.GA26923@1wt.eu> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Authentication-Results: mail.lichtvoll.de; auth=pass smtp.auth=martin smtp.mailfrom=martin@lichtvoll.de Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org Willy Tarreau - 17.09.19, 07:24:38 CEST: > On Mon, Sep 16, 2019 at 06:46:07PM -0700, Matthew Garrett wrote: > > >Well, the patch actually made getrandom() return en error too, but > > >you seem more interested in the hypotheticals than in arguing > > >actualities.> > > If you want to be safe, terminate the process. > > This is an interesting approach. At least it will cause bug reports in > application using getrandom() in an unreliable way and they will > check for other options. Because one of the issues with systems that > do not finish to boot is that usually the user doesn't know what > process is hanging. A userspace process could just poll on the kernel by forking a process to use getrandom() and waiting until it does not get terminated anymore. And then it would still hang. So yes, that would it make it harder to abuse the API, but not impossible. Which may still be good, I don't know. Either the kernel does not reveal at all whether it has seeded CRNG and leaves GnuPG, OpenSSH and others in the dark, or it does and risk that userspace does stupid things whether it prints a big fat warning or not. Of course the warning could be worded like: process blocking on entropy too early on boot without giving the kernel much chance to gather entropy. this is not a kernel issue, report to userspace developers And probably then kill the process, so at least users will know. 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. 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, but it does not replace talking with userspace developers and it would need some time to allow for adapting userspace applications and services. -- Martin