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=-0.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 82C03C4CEC9 for ; Fri, 20 Sep 2019 22:45:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4BACE20C01 for ; Fri, 20 Sep 2019 22:45:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569019501; bh=+u2HI0skstdjb3glWqOntyrhxc7RXPu26XVe9jd07Fc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=f6kpYjZap9GVwmz5IHprb0fUCV5VcKuIoJ318kvDncQ3T4VII10lOCD1Pk8SCPlUy zkKLudk4BWiRoQsMyywJ36UUjURnYPv15w0uQxQG+6xTrsPCucpy6GhZ19YXL9cqDZ dAuhso7gynB6WRqg60hk0Qe1xn7vwsfHvE3gJ3w0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406270AbfITWpA (ORCPT ); Fri, 20 Sep 2019 18:45:00 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:40838 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393839AbfITWo5 (ORCPT ); Fri, 20 Sep 2019 18:44:57 -0400 Received: by mail-lj1-f195.google.com with SMTP id 7so8526750ljw.7 for ; Fri, 20 Sep 2019 15:44:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GKUuDO6YOo0r9Dt4w/cxI9Tu6lVFdn1V9F8DKhykytQ=; b=Kl/zSV5hhzVT49bbAiGHnAK2P122IBZjE+QpwN3a9ptugitLNiKFgEkjvUJAFPy4yA j1qvQnw5/ZusJG8Zxho5k5dtJV/gOUtrQJ0v2WclFfrSVNQ6IuFX1I+yu0eZpF6xMiU/ /PwDzWilWgoTYlFoB6C14j2XRyqO+E101Fbs8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GKUuDO6YOo0r9Dt4w/cxI9Tu6lVFdn1V9F8DKhykytQ=; b=kcHiY6vJNhzWMwMnTfZFOcuBXaqFwcdO7wWLkwkS8Ne+49O6WYJUEqCvOcY1O0GTkG piUovcrKv4FJ8Ijd6sX5xYOIEQxYQNh8YpnRxIE6xslIqabCIdSpdOGPTrXjMU9/WYRT GO0laQbIkSpHU67j3Hnbti7+v2TSxHwOIYNn6Mmq+0Hn/LUwA9OVmDXiDssgTvSSKfPr TQUA+a1pAZwscAEzoKq6O+DjmiWiPnAiLPebmAV9r7Y9TNf2P6zRskVEKkGtVYQhUQX2 E8oFzkB+AIB99dhSkoZMFjEHtLzWehB1o33ears655OTW7P/goG2yNPawoSjgZ9hU+P/ 08gQ== X-Gm-Message-State: APjAAAXLT7mTqo1dSVgHNXGC9lgBrJ6jExJ8LnJVqeFYdvhsU5Cmt9Q6 6blc+OJ9idd7cDaCDd1MjPMx61ey3dQ= X-Google-Smtp-Source: APXvYqzkyZAh+rT4yXRjkxf51CsLxW6RlJEjKsbMwg9zKPZNxQBx/6lHMNsJBCRoo011hLFKGa9JAQ== X-Received: by 2002:a2e:808d:: with SMTP id i13mr5489285ljg.73.1569019495523; Fri, 20 Sep 2019 15:44:55 -0700 (PDT) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com. [209.85.208.178]) by smtp.gmail.com with ESMTPSA id m18sm736720lfb.73.2019.09.20.15.44.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 15:44:53 -0700 (PDT) Received: by mail-lj1-f178.google.com with SMTP id j19so7050464lja.1 for ; Fri, 20 Sep 2019 15:44:52 -0700 (PDT) X-Received: by 2002:a2e:5b9a:: with SMTP id m26mr10397369lje.90.1569019492155; Fri, 20 Sep 2019 15:44:52 -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: Linus Torvalds Date: Fri, 20 Sep 2019 15:44:35 -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: Andy Lutomirski Cc: "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-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org 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. > In other words, I want GRND_SECURE_BLOCKING and /dev/random reads to > genuinely always work and to genuinely never take much longer than 5s. > I don't want a special case where they fail. Honestly, if that's the case and we _had_ such a methoc of initializing the rng, then I suspect we could just ignore the flags entirely, with the possible exception of GRND_NONBLOCK. And even that is "possible exception", because once your worst-case is a one-time delay of 5s at boot time thing, you might as well consider it nonblocking in general. Yes, there are some in-kernel users that really can't afford to do even that 5s delay (not just may they be atomic, but more likely it's just that we don't want to delay _everything_ by 5s), but they don't use the getrandom() system call anyway. > The exposed user APIs are, subject to bikeshedding that can happen > later over the actual values, etc: So the thing is, you start from the impossible assumption, and _if_ you hold that assumption then we might as well just keep the existing "zero means blocking", because nobody mind. I'd love to say "yes, we can guarantee good enough entropy for everybody in 5s and we don't even need to warn about it, because everybody will be comfortable with the state of our entropy at that point". It sounds like a _lovely_ model. But honestly, it simply sounds unlikely. Now, there are different kinds of unlikely. In particular, if you actually have a CPU cycle counter that actually runs at least on the same order of magnitude as the CPU frequency - then I believe in the jitter entropy more than in many other cases. Sadly, many platforms don't have that kind of cycle counter. I've also not seen a hugely believable "yes, the jitter entropy is real" paper. Alexander points to the existing jitterentropy crypto code, and claims it can fill all our entropy needs in two seconds, but there are big caveats: (a) that code uses get_random_entropy(), which on a PC is that nice fast TSC that we want. On other platforms (or on really old PC's - we technically support CPU's still that don't have rdtsc)? It might be zero. Every time. (b) How was it tested? There are lots of randomness tests, but most of them can be fooled with a simple counter through a cryptographic hash - which you basically need to do anyway on whatever entropy source you have in order to "whiten" it. It's simply _really_ hard to decide on entropy. So it's really easy to make the randomness of some input look really good, without any real idea how good it truly is. And maybe it really is very very good on one particular machine, and then on another one (with either a simpler in-order core or a lower-frequency timestamp counter) it might be horrendously bad, and you'll never know, So I'd love to believe in your simple model. Really. I just don't see how to get there reliably. Matthew Garrettpointed to one analysis on jitterentropy, and that one wasn't all that optimistic. I do think jitterentropy would likely be good enough in practice - at least on PC's with a TSC - for the fairly small window at boot and getrandom(0). As I mentioned, I don't think it will make anybody _happy_, but it might be one of those things where it's a compromise that at least works for people, with the key generation people who are really unhappy with it having a new option for their case. And maybe Alexander can convince people that when you run the jitterentropy code a hundred billion times, the end result (not the random stream from it, but the jitter bits themselves - but I'm not even sure how to boil it down) - really is random. Linus