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 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 687F3C3A5A2 for ; Fri, 20 Sep 2019 14:34:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3A7052086A for ; Fri, 20 Sep 2019 14:34:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568990061; bh=5T/4VfiO/HqhsBQATWPC19/qw+SPrKZRtyV53KT0GwQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=wtMNVyxG6CD7DRhnzzH2W+H1IB5KFNg6MtBMvWpxR2ki3jH2mm8LMEO+Gkhygjspc o9n4m4319tWbJClcp9nRg+LdvAiHcyzyrKtF/YMEk4io2XHnmNf1Qhthrm26NR/9TZ NrwIa7urk8+uDQ3IX+WPvHaWHAN4pYPN4tYh4P98= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391682AbfITOeT (ORCPT ); Fri, 20 Sep 2019 10:34:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:46826 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2391631AbfITOeB (ORCPT ); Fri, 20 Sep 2019 10:34:01 -0400 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) (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 8FBC12190F for ; Fri, 20 Sep 2019 14:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568990040; bh=5T/4VfiO/HqhsBQATWPC19/qw+SPrKZRtyV53KT0GwQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ERG/TepvuolOT6Mw8ez/j7trPLA7A2UHhgppUbM1UKt5I3anQ/LyiAyc1Gzj2TlKM sADxzjaDUCB5buPl3eS2UovJkkkCM5lajx430tmkdOhaMKDDGW+G/nttRZzcXhrsdr zAieZhwuQe6tN6TAp81EjJVKtEqxNKxDSB5o4mHU= Received: by mail-wr1-f52.google.com with SMTP id n14so6984599wrw.9 for ; Fri, 20 Sep 2019 07:34:00 -0700 (PDT) X-Gm-Message-State: APjAAAWjEmPtiUebluAdFWXBhVS88fE21FfuypzjpAE4IvQRSjLL75CU 5EmHgjFbE8sIjpryKeuC0ihIR/FodyAmYF/DfL9TVA== X-Google-Smtp-Source: APXvYqw97uK1m0GzlqxXwrKua5Pdc2B9TF8UZRisIXGn8aSTnAlq1AfsIBHJ3uk1lXhVKnKKQuKNgHptfa8+mPFi7KY= X-Received: by 2002:adf:fe0f:: with SMTP id n15mr12713274wrr.343.1568990038968; Fri, 20 Sep 2019 07:33:58 -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: <20190920134609.GA2113@pc> From: Andy Lutomirski Date: Fri, 20 Sep 2019 07:33:47 -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: "Ahmed S. Darwish" Cc: Linus Torvalds , 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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 20, 2019 at 6:46 AM Ahmed S. Darwish wrote: > > Hi, > > On Wed, Sep 18, 2019 at 04:57:58PM -0700, Linus Torvalds wrote: > > On Wed, Sep 18, 2019 at 2:17 PM Ahmed S. Darwish wrote: > > > > > > Since Linux v3.17, getrandom(2) has been created as a new and more > > > secure interface for pseudorandom data requests. It attempted to > > > solve three problems, as compared to /dev/urandom: > > > > I don't think your patch is really _wrong_, but I think it's silly to > > introduce a new system call, when we have 30 bits left in the flags of > > the old one, and the old system call checked them. > > > > So it's much simpler and more straightforward to just introduce a > > single new bit #2 that says "I actually know what I'm doing, and I'm > > explicitly asking for secure/insecure random data". > > > > And then say that the existing bit #1 just means "I want to wait for entropy". > > > > So then you end up with this: > > > > /* > > * Flags for getrandom(2) > > * > > * GRND_NONBLOCK Don't block and return EAGAIN instead > > * GRND_WAIT_ENTROPY Explicitly wait for entropy > > * GRND_EXPLICIT Make it clear you know what you are doing > > */ > > #define GRND_NONBLOCK 0x0001 > > #define GRND_WAIT_ENTROPY 0x0002 > > #define GRND_EXPLICIT 0x0004 What is this GRND_EXPLICIT thing? A few weeks ago, I sent a whole series to address this, and I obviously didn't cc enough people. I'll resend a rebased version today. Meanwhile, some comments on this whole mess: As I think everyone mostly agrees in this whole thread, getrandom() can't just magically start returning non-random results. That would be a big problem. Linus, I disagree that blocking while waiting for randomness is an error. Sometimes you want to generate a key, you want to finish as quickly as possible, and you don't want to be in the business of fiddling with the setup of the kernel RNG. I would argue that *most* crypto applications are in this category. I think that the kernel should, instead, handle this mess itself. As a first pass, it could be as simple as noticing that someone is blocking on randomness and kicking off a thread that does some randomish reads to the rootfs. This would roughly simulate the old behavior in which an ext4 rootfs did more IO than necessary. A fancier version would, as discussed in this thread, do more clever things. (As an aside, I am not a fan of xoring or adding stuff to the CRNG state. We should just use an actual crypto primitive for this. Accumulate the state in a buffer and SHA-512 it. Or use something like the Keccak duplex sponge. But this is a discussion for another day.) So I'm going to resend my series. You can all fight over whether the patch that actually goes in should be based on my series or based on this patch. --Andy