From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92007C4CECD for ; Mon, 16 Sep 2019 19:09:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 77714206C2 for ; Mon, 16 Sep 2019 19:09:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390743AbfIPTJ1 (ORCPT ); Mon, 16 Sep 2019 15:09:27 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:46279 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390662AbfIPTJ1 (ORCPT ); Mon, 16 Sep 2019 15:09:27 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8GJ8xTE025965; Mon, 16 Sep 2019 21:08:59 +0200 Date: Mon, 16 Sep 2019 21:08:59 +0200 From: Willy Tarreau To: Linus Torvalds Cc: "Theodore Y. Ts'o" , 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 Subject: Re: Linux 5.3-rc8 Message-ID: <20190916190858.GD24547@1wt.eu> References: <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: User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 16, 2019 at 10:44:31AM -0700, Linus Torvalds wrote: > - 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. I think we can keep a flag to work like the current /dev/random and deplete entropy for the very rare cases where it's really desired to run this way (maybe even just for research), but it should require special permissions as it impacts the whole system. I think that your GRND_SECURE above means the current 0 situation, where we wait for initial entropy then not wait anymore, right ? If so it could remain the default setting, because at least it will not betray applications which rely on this reliability. And GRND_INSECURE will be decided on a case by case basis by applications that are caught waiting like sfdisk in initramfs or a MAC address generator for example. In this case it could even be called GRND_PREDICTABLE maybe to enforce its property compared to others. My guess is that we can fix the situation because nobody likes the problems that sporadically hit users. getrandom() was adopted quite quickly to solve issues related to using /dev/*random in chroots, I think the new flags will be adopted by those experiencing issues. Just my two cents, Willy