Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp5647348ybe; Tue, 17 Sep 2019 11:14:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqwxNVH4oDDH2hf6z3iN9upDF92lL+LkJiS123ZIuo4nKnpxc+T18FsOEyc3vrJ+B6bX1eCu X-Received: by 2002:a50:f04e:: with SMTP id u14mr6145744edl.247.1568744048992; Tue, 17 Sep 2019 11:14:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568744048; cv=none; d=google.com; s=arc-20160816; b=u7S4heRf+1rwpxIpvh3mhwkoUQnwo7/LUoONdbTz0SDJ0lPM64+SSNCHXuzqBywSj+ Cvs6/jpxA6NHPBVmKbIdLk0bHOfuT7CAcsPi8+NN4QQqB9puJ3+UPlNx45JpRVHMQxxj HZxkm7h9C/7k0KTXTHU4dZdfm0BwWAJsiEZK2Osp1+gVhj8ZTUuDd4pM4JtpexZv1mx7 Z2mRLoxQYhUlaMsWjhHCAGMtX5HMEEpN8EmPRS8NwxungZ6D4sO+taXv0lMfsTKa20JM qE2aUQiPZ81ODqWVLh88rQfwvR5Ouh2fFn3qV1d64Q2tCoNXhDUXxCNuttNUaP4Y0ngj Ts3A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=uvPCezbkNr/5XIn/IUqyiFwXiO74VOq0qFVXDTPln7A=; b=kZOxH2Kye7O0uoTiIBzFIo+PjvabRq/H7D+cdCIZsW/XhP6WNDJsi3ALxV5a5BDjo8 3G/GnCZxmDr763v3mQfocD2Q8cccKk4NVbTlgrO7eiXrsM2VluJb5TOU2lrj8DZmWOgR Yn79nG+k2Wh+CqQ5mK1wH4PnUIU7qu0wH0qCxOKchajKOvycesprRrdG3XcrPwUGc98e gDiU3nPowivIQ6yLFdQ4PBryDycntJFFmv3lLcIwe2zPmGniybn32kLUmqENxqH0jPSj J+4m6aBtiKeslYOuXe6pMCp0LT+k9Dkfsg/eqEkGVmMpKGYZ4rYFxwJwytPYOuYFo9UY mcLg== 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 k6si1594247ejj.177.2019.09.17.11.13.44; Tue, 17 Sep 2019 11:14:08 -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 S1726882AbfIQPc4 (ORCPT + 99 others); Tue, 17 Sep 2019 11:32:56 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:40460 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726724AbfIQPcz (ORCPT ); Tue, 17 Sep 2019 11:32:55 -0400 Received: from gardel-login.0pointer.net (gardel.0pointer.net [85.214.157.71]) by gardel.0pointer.net (Postfix) with ESMTP id 4E947E80FFC; Tue, 17 Sep 2019 17:32:53 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id C7EDE160ADC; Tue, 17 Sep 2019 17:32:52 +0200 (CEST) Date: Tue, 17 Sep 2019 17:32:52 +0200 From: Lennart Poettering To: "Theodore Y. Ts'o" Cc: Linus Torvalds , Willy Tarreau , Vito Caputo , "Ahmed S. Darwish" , 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: <20190917153252.GA31567@gardel-login> References: <20190915065142.GA29681@gardel-login> <20190916014050.GA7002@darwi-home-pc> <20190916014833.cbetw4sqm3lq4x6m@shells.gnugeneration.com> <20190916024904.GA22035@mit.edu> <20190916042952.GB23719@1wt.eu> <20190916061252.GA24002@1wt.eu> <20190916172117.GB15263@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190916172117.GB15263@mit.edu> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mo, 16.09.19 13:21, Theodore Y. Ts'o (tytso@mit.edu) wrote: > We could create a new flag, GRND_INSECURE, which never blocks. And > that that allows us to solve the problem for silly applications that > are using getrandom(2) for non-cryptographic use cases. Use cases > might include Python dictionary seeds, gdm for MIT Magic Cookie, UUID > generation where best efforts probably is good enough, etc. The > answer today is they should just use /dev/urandom, since that exists > today, and we have to support it for backwards compatibility anyway. > It sounds like gdm recently switched to getrandom(2), and I suspect > that it's going to get caught on some hardware configs anyway, even > without the ext4 optimization patch. So I suspect gdm will switch > back to /dev/urandom, and this particular pain point will probably go > away. The problem is that reading from /dev/urandom at a point where it's not initialized yet results in noisy kernel logging on current kernels. If you want people to use /dev/urandom then the logging needs to go away, because it scares people, makes them file bug reports and so on, even though there isn't actually any problem for these specific purposes. For that reason I'd prefer GRND_INSECURE I must say, because it indicates people grokked "I know I might get questionnable entropy". Lennart