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 B0FE8C4CEC9 for ; Sat, 21 Sep 2019 03:06:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 91B952080F for ; Sat, 21 Sep 2019 03:06:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406848AbfIUDGD (ORCPT ); Fri, 20 Sep 2019 23:06:03 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:49432 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729387AbfIUDGC (ORCPT ); Fri, 20 Sep 2019 23:06:02 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8L35l8v002407; Sat, 21 Sep 2019 05:05:47 +0200 Date: Sat, 21 Sep 2019 05:05:47 +0200 From: Willy Tarreau To: Andy Lutomirski Cc: Linus Torvalds , "Ahmed S. Darwish" , Lennart Poettering , "Theodore Y. Ts'o" , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Matthew Garrett , lkml , Ext4 Developers List , Linux API , linux-man Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2() Message-ID: <20190921030547.GF1889@1wt.eu> References: <20190920134609.GA2113@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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 20, 2019 at 04:30:20PM -0700, Andy Lutomirski wrote: > So I think that just improving the > getrandom()-is-blocking-on-x86-and-arm behavior, adding GRND_INSECURE > and GRND_SECURE_BLOCKING, and adding the warning if 0 is passed is > good enough. I think so as well. Anyway, keep in mind that *with a sane API*, userland can improve very quickly (faster than kernel deployments in field). But userland developers need reliable and testable support for features. If it's enough to do #ifndef GRND_xxx/#define GRND_xxx and call getrandom() with these flags to detect support, it's basically 5 reliable lines of code to add to userland to make a warning disappear and/or to allow a system that previously failed to boot to now boot. So this gives strong incentive to userland to adopt the new API, provided there's a way for the developer to understand what's happening (which the warning does). If we do it right, all we'll hear are userland developers complaining that those stupid kernel developers have changed their API again and really don't know what they want. That will be a good sign that the warning flows back to them and that adoption is taking. And if the change is small enough, maybe it could make sense to backport it to stable versions to fix boot issues. With a testable feature it does make sense. Willy