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=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 E93F8C4CEC9 for ; Fri, 20 Sep 2019 23:30:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BCC5F2080F for ; Fri, 20 Sep 2019 23:30:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569022235; bh=WnMayVa2/XDvHL1e+7jmVvQ/LflCEEfThR3A/O6WAe0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=O9fdt3W/OC4BJWGyifT2gEAvCVHaQs/KhiCpaVvPs7ZykHvdL2nRIim+Om02msyyV 0VDbu7l2gBtFkHFGJMEzJmO9Mn6//Qo9EFFF/rp10PX3gPcCa7Wqj9HNGNBQzKwnTC brSvY68oeK5s2pZ1IlAXwJMa6OE8VfOtB9i2JvHQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405066AbfITXaf (ORCPT ); Fri, 20 Sep 2019 19:30:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:46518 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404967AbfITXaf (ORCPT ); Fri, 20 Sep 2019 19:30:35 -0400 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DB1B221882 for ; Fri, 20 Sep 2019 23:30:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569022234; bh=WnMayVa2/XDvHL1e+7jmVvQ/LflCEEfThR3A/O6WAe0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MDD97AOK7h1yXKTkH80poLtBNE96X2T5kJ98AMCn2EJoMnuaKS+R8hY1QSnwRhIw6 n8/ucSaPzuQvrsD9Uz3Oo9KrMF4/WwiIGoBzcPKEcrHGmFD/tw6nOOADNtLx9N982o YldrD65lYj0eN1ent3+i64cVSojAaqSDLXJqAZaU= Received: by mail-wr1-f53.google.com with SMTP id i1so8333378wro.4 for ; Fri, 20 Sep 2019 16:30:33 -0700 (PDT) X-Gm-Message-State: APjAAAWfPr/mB1FslgoeZruUBekGYz5GpaeY3T+PuD5cd+IAmtv520pk 7Zf2QaO9/NGycWzmNMGR206Cj4TYErpzwX/ls+DktQ== X-Google-Smtp-Source: APXvYqzX4CwBJfqfTYtsfZiWbwOGIEcas93ymXw8ez4QvH3rwZ04YTXpTAYLf/0PldtRhMHifaqzsBGLqgFhr6R4V4Q= X-Received: by 2002:a5d:4c92:: with SMTP id z18mr12974870wrs.111.1569022232290; Fri, 20 Sep 2019 16:30:32 -0700 (PDT) MIME-Version: 1.0 References: <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914122500.GA1425@darwi-home-pc> <008f17bc-102b-e762-a17c-e2766d48f515@gmail.com> <20190915052242.GG19710@mit.edu> <20190918211503.GA1808@darwi-home-pc> <20190918211713.GA2225@darwi-home-pc> <20190920134609.GA2113@pc> In-Reply-To: From: Andy Lutomirski Date: Fri, 20 Sep 2019 16:30:20 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2() To: Linus Torvalds Cc: Andy Lutomirski , "Ahmed S. Darwish" , Lennart Poettering , "Theodore Y. Ts'o" , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Willy Tarreau , Matthew Garrett , lkml , Ext4 Developers List , Linux API , linux-man 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 Archived-At: List-Archive: List-Post: On Fri, Sep 20, 2019 at 3:44 PM Linus Torvalds wrote: > > On Fri, Sep 20, 2019 at 1:51 PM Andy Lutomirski wrote: > > > > To be clear, when I say "blocking", I mean "blocks until we're ready, > > but we make sure we're ready in a moderately timely manner". > > .. an I want a pony. > > The problem is that you start from an assumption that we simply can't > seem to do. Eh, fair enough, I wasn't thinking about platforms without fast clocks. I'm very nervous about allowing getrandom(..., 0) to fail with -EAGAIN, though. On a very, very brief search, I didn't find any programs that would incorrectly assume it worked, but I can easily imagine programs crashing, and that might be bad, too. At the end of the day, most user programmers who call getrandom() really did notice that we flubbed the ABI, and either they were too lazy to fall back to /dev/urandom, or they didn't want to for some reason, or they genuinely want the blocking behavior. And people who work with little embedded systems without good clocks that basically can't generate random numbers already know this, and they have little scripts to help out. 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 suppose we could also have separate GRND_SECURE_BLOCKING and GRND_SECURE_BLOCK_FOREVER. We could also say that, if you want to block forever, you should poll() on /dev/random (with my patches applied, where this actually does what users would want). --Andy