Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4567518ybe; Mon, 16 Sep 2019 14:36:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqxMwli9pIDlQ0Ru15MbQawy7nZT2PC+6RmxKmAopwJeEfhmyPw+9nTgSZOjKR7/zwScJ4Ol X-Received: by 2002:a50:f045:: with SMTP id u5mr1395692edl.297.1568669768034; Mon, 16 Sep 2019 14:36:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568669768; cv=none; d=google.com; s=arc-20160816; b=sMPeQyAYTkqoscgYUVi1t0CrSNBIOYpPtxj2KAI1fi0Yu9j1KFv7h0vBFsjYmCDHPG W9YdR7K7gapyeHwdeu7LSx7X5INqm7WLnwxPmNP0wJbFO9pZBA6+b5pD+ydxPw2fb736 S5cwBwDA8aeqahOEveELr06Hm11B0AGCnmSOE8ZVbUuFAfUfmla9eQLxpdk8wdnLcFEy ctWFFS3Wi2cDT8DljB+RCO4i1DQdxliMk0OOuYhUW+U8e3hh7voFQodSsPOe8AdjqvAu 85uxDqoMyHd10U1ULfdxV5t4y/CMqFy09obrqdG5hCiwWoninpDmtLQF1TOzInaw11Li RgBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=uipfU8HulVEUTGxV4YdJJv+JjF46ahJtoBSAjnbUb1c=; b=TKwUzkcxB6hjXx0WZqJH1oXXDIqmL5notGpy7btqiQHS+NqludhSfWW18GAOtqwpzJ KYifKr7CFd4DjGqdzvR0xPeVVB20zqNDpyRErpRYDgk/1cpWfPsnS88jlz9NqB1tIRa4 ij8j1KNSWOFlS1/Qsrmy/JsuYj3dq8nWc/XfJfVhzAvia0RfWhACs3d6eQyov/0oGz/3 5zqVM13rcUZGIuw6E717I+A+KLg+wwYEvKuVSrqbfcgdOGUhaT0TZXo4CUozgB00Imey Dis+ZdQ4vRKG/GiWMTsK0PCtDc7kH8L8MM+K1zZj1ARlFgf5EfGWM9VddhgszG7k0G09 gpNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=WOAENpjp; 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 h20si210795edb.218.2019.09.16.14.35.43; Mon, 16 Sep 2019 14:36: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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=WOAENpjp; 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 S1729703AbfIPRoy (ORCPT + 99 others); Mon, 16 Sep 2019 13:44:54 -0400 Received: from mail-lj1-f180.google.com ([209.85.208.180]:38743 "EHLO mail-lj1-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729630AbfIPRoy (ORCPT ); Mon, 16 Sep 2019 13:44:54 -0400 Received: by mail-lj1-f180.google.com with SMTP id y23so777212ljn.5 for ; Mon, 16 Sep 2019 10:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uipfU8HulVEUTGxV4YdJJv+JjF46ahJtoBSAjnbUb1c=; b=WOAENpjpGuUZ7Alp1ItN7/TmlL8bcS9/Z3/xKjjIfN0YI+SYYMoGtITKjTdjBG2d5a J0Cbfi+4Uwsz+z7yaG3a/IhY1bqDJQpmQGM2M5pJ/Xy8SFGFV9201+C9pU6KQyoTOGfa ZGgqDD3A0QEo81MYj1+6xzf+KpLWD6hKgAAx8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uipfU8HulVEUTGxV4YdJJv+JjF46ahJtoBSAjnbUb1c=; b=kU9PFFMU3jT11wWY7bLFkK3LrxHIlrMKXMLxCi83e5c9heNKE9Bz7+jjgWRG6BMwT3 xKewGWfI7w5K8lt69fM2DC2GFa3TyXy01uD1rETNd/wmY5vYUoTxKffdfiiP6/ywBwmw XPPSwYKL+Cx9D+gzoj9ijfQah2oq7y1vamZ7NNt1rnLwo99NbSWh/4xwlFbN2CNGeXqd xofxaW7gj+WzP3UMAl9ZUAIy5tltwstZcjQRT9zbvqHiXuNm3SB0yn/AVGW4IzwqkPWG dPR3hysoxyln/XO9ZFTkWYQDLtIfXcVWDapbXE6ka0Qecy5tfww1CHbMQUpcZJaVbbCp Z/Qg== X-Gm-Message-State: APjAAAXPUsddwW34vhapTebFq3XB9Ep0of8dMNPFkM7pYyEDDMWjj5nd z4TrR/uXcgV8HYBjyEpJ1QgzLEPTup0= X-Received: by 2002:a2e:654a:: with SMTP id z71mr437541ljb.37.1568655890405; Mon, 16 Sep 2019 10:44:50 -0700 (PDT) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com. [209.85.167.51]) by smtp.gmail.com with ESMTPSA id z72sm8583344ljb.98.2019.09.16.10.44.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Sep 2019 10:44:49 -0700 (PDT) Received: by mail-lf1-f51.google.com with SMTP id r22so678381lfm.1 for ; Mon, 16 Sep 2019 10:44:48 -0700 (PDT) X-Received: by 2002:ac2:5a4c:: with SMTP id r12mr339324lfn.52.1568655888261; Mon, 16 Sep 2019 10:44:48 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <20190916172117.GB15263@mit.edu> From: Linus Torvalds Date: Mon, 16 Sep 2019 10:44:31 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Linux 5.3-rc8 To: "Theodore Y. Ts'o" Cc: Willy Tarreau , Vito Caputo , "Ahmed S. Darwish" , Lennart Poettering , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, lkml Content-Type: text/plain; charset="UTF-8" Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Sep 16, 2019 at 10:21 AM Theodore Y. Ts'o 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. Note that getting "reasonably good random numbers" is definitely not silly. If you are doing things like just shuffling a deck of cards for playing solitaire on your computer, getting a good enough source of randomness is nontrivial. Using getrandom() for that is a _very_ valid use. But it obviously does not need _secure_ random numbers. It is, in fact, _so_ random that we give that AT_RANDOM thing to every new process because people want things like that. Sadly, people often aren't aware of it, and don't use that as much as they could. (Btw, we should probably also mix in other per-process state, because right now people have actually attacked the boot-time AT_RANDOM to find canary data etc). So I think you are completely out to lunch by calling these "insecure" things "silly". They are very very common. *WAY* more common than making a long-term secure key will ever be. There's just a lot of use of reasonable randomness. You also are ignoring that we have an existing problem with existing applications. That happened exactly because those things are so common. So here's my suggestion: - admit that the current situation actually causes problems, and has _existing_ bugs. - throw it out the window, with the timeout and big BIG warning when the problem cases trigger - add new GRND_SECURE and GRND_INSECURE flags that have the actual useful behaviors that we currently pretty much lack - consider the old 0-3 flag values legacy, deprecated, and unsafe because they _will_ time out to fix the existing problem we have right now because of their bad behavior. And stop with the "insecure is silly". Insecure is not silly, and in fact should have been the default, because (a) insecure is and basically always will be the common case by far (b) insecure is the "not thinking about it" case and should thus be default and that (b) is also very much why 0 should have been that insecure case. Part of the problem is exactly the whole "_normally_ it just works, so using 0 without thinking about it tests out well". Which is why getrandom(0) is the main problem we face. Because defaults matter. Linus