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 5CA96C4CECD for ; Tue, 17 Sep 2019 05:25:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3AB7E206C2 for ; Tue, 17 Sep 2019 05:25:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2392373AbfIQFZK (ORCPT ); Tue, 17 Sep 2019 01:25:10 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:46631 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391179AbfIQFZK (ORCPT ); Tue, 17 Sep 2019 01:25:10 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8H5OckJ026945; Tue, 17 Sep 2019 07:24:38 +0200 Date: Tue, 17 Sep 2019 07:24:38 +0200 From: Willy Tarreau To: Matthew Garrett Cc: 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: <20190917052438.GA26923@1wt.eu> References: <20190916230217.vmgvsm6o2o4uq5j7@srcf.ucam.org> <20190916231103.bic65ab4ifv7vhio@srcf.ucam.org> <20190916232922.GA7880@darwi-home-pc> 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-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org 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. Anyway regarding the impact on applications relying on getrandom() for security, I'm in favor of not *silently* changing their behavior and provide a new flag to help others get insecure randoms without waiting. With your option above we could then have this way to go: - GRND_SECURE: the application wants secure randoms, i.e. like the current getrandom(0), waiting for entropy. - GRND_INSECURE: the application never wants to wait, it just wants a replacement for /dev/urandom. - GRND_RANDOM: unchanged, or subject to CAP_xxx, or maybe just emit a "deprecated" warning if called without a certain capability, to spot potentially harmful applications. - by default (0), the application continues to wait but when the timeout strikes (30 seconds ?), it gets terminated with a message in the logs for users to report the issue. After some time all relevant applications which accidently misuse getrandom() will be fixed to either use GRND_INSECURE or GRND_SECURE and be able to wait longer if they want (likely SECURE|NONBLOCK). Willy