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.5 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 2DE99C47404 for ; Thu, 12 Sep 2019 11:58:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0B85E20856 for ; Thu, 12 Sep 2019 11:58:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731470AbfILL6u (ORCPT ); Thu, 12 Sep 2019 07:58:50 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:43287 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730386AbfILL6t (ORCPT ); Thu, 12 Sep 2019 07:58:49 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8CBwOk1011171; Thu, 12 Sep 2019 13:58:24 +0200 Date: Thu, 12 Sep 2019 13:58:24 +0200 From: Willy Tarreau To: Linus Torvalds Cc: "Theodore Y. Ts'o" , "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: <20190912115824.GB11016@1wt.eu> References: <20190910173243.GA3992@darwi-home-pc> <20190911160729.GF2740@mit.edu> <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@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 Thu, Sep 12, 2019 at 12:34:45PM +0100, Linus Torvalds wrote: > An alternative might be to make getrandom() just return an error > instead of waiting. Sure, fill the buffer with "as random as we can" > stuff, but then return -EINVAL because you called us too early. That's probably one of the most sensible approaches. I must say I feel quite annoyed by what randomness has become due to the misuse of poor random sources by security components suddenly forcing all these sources to become strong and having to become unavailable for everything which doesn't need strong random. And most of the time the stuff which doesn't need a strong random happens during early boot. It can range from issuing a MAC address before setting a link up (when you have no chance to get entropy) to providing a UUID for a file system, or use of ephemeral randoms for session keys for the first access to a device for its configuration. A number of these often end up with a system not booting, unable to self-configure itself, or not being available when expected. It's too late now to change existing applications, but probably that doing something like above would at least allow applications to implement a fall back with the choice of "hey Mr user, there's not enough entropy yet to propose you a secure password, so please type 20 random chars on the keyboard so that I can complete it", or conversely "the syscall failed but I know I can still use the buffer's contents for a MAC address". But having to make the syscall to wait longer is never going to serve anyone. Two minutes is an eternity for certain devices, and some from the security world will consider that the syscall waited long enough to produce a good security so it's OK to use it as a reliable source. Failing immediately with whatever could be obtained is by far the best solution in my opinion as the application has to take the responsibility for using that buffer's contents. Willy -- still dreaming about the day boot loaders will collect entropy from the DDR training phase and pass it to the kernel.