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,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 8EB72C4CEC9 for ; Sat, 14 Sep 2019 19:19:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 57A312081B for ; Sat, 14 Sep 2019 19:19:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1568488785; bh=ouScJnt26pzP69fgyglFbrcV+rBmS6ZulHjP8wEhBGA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=WfeJlXJwhh+QvndlBTCfpytJwAFRdgKFP5YVvg0OTUF7Y1/uMBFLxJGxssggB6zYC LfZOKI7uYAqgGPBxQCgjjM0wn4iw/q8pbkcLbuJR9nCOnq2Xm1u/kclGVe7ASdilQf C/eE49c3Mg9sbuNkrpLR9iVT6uyVfkpQ075ZbVlA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728618AbfINTTo (ORCPT ); Sat, 14 Sep 2019 15:19:44 -0400 Received: from mail-lj1-f193.google.com ([209.85.208.193]:38567 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727975AbfINTTo (ORCPT ); Sat, 14 Sep 2019 15:19:44 -0400 Received: by mail-lj1-f193.google.com with SMTP id y23so29776449ljn.5 for ; Sat, 14 Sep 2019 12:19:43 -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=iPQUiN+MJCiURQJKXosBWd3fof3PGiz/eGjFjKhHooQ=; b=WnL0j3pyjxPnM4hyGPIMKPvliWuoPrHkG3hgdyb3sUJcufozYIh7VZ+bBUf44lWAB4 pcl0tDtzPQqDxymM/g3YLvtkLjejtwFbg4lioNHR9dtkICNJTYZ6/F3XTY/AgKJG9z1d EuP51x7okTZmjwEK/BHlvdQaggkLC8U+lNfw8= 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=iPQUiN+MJCiURQJKXosBWd3fof3PGiz/eGjFjKhHooQ=; b=B1+Q8+LJls6O/ToR2PIxqGt2pnm5CX7PwmQYBiK74CiE3+0wHvLaOWG27I+h9ixjPP 1I+9+rg5aoBgIthxc9qpnasqDhe0+HOd20TiiH98xSCCzCbnMxwAeik3ZipvtLpx/TJY m1sul4QyRRktPy196xXxkGhIx63j1aSz96EpjwbC1jExGUh1gO4v27kbQhsYXU6rS8J0 wxrz5hcirVWlbVkmmzUQWnuffx3URwYdpWpaA4WL6UKzbb7THLw6itD7ztXk/JkY2N+A huBKDZmPC6Pss39c7QrQCudRwjp76W2vuntBpkhRBSZ7mIihgsokwmulWLq1bgscds3i poYQ== X-Gm-Message-State: APjAAAWNOy4sofaRF9lWzbSV86QhnAS5uR6Z/96629Wzj+vyuLkCRzvV 8AVdX2yIIxUg4cg3hbYhaP+MHh+RsEU= X-Google-Smtp-Source: APXvYqy4aWKzQA5Khrf1hJEKUwzJo87JqEerBhm7RzoIK39YfCvpXN7YxRtuUVA0HfAVBq8JNoXnOw== X-Received: by 2002:a05:651c:292:: with SMTP id b18mr34299459ljo.131.1568488781574; Sat, 14 Sep 2019 12:19:41 -0700 (PDT) Received: from mail-lj1-f180.google.com (mail-lj1-f180.google.com. [209.85.208.180]) by smtp.gmail.com with ESMTPSA id n9sm4956312ljh.53.2019.09.14.12.19.39 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Sep 2019 12:19:40 -0700 (PDT) Received: by mail-lj1-f180.google.com with SMTP id q64so19597069ljb.12 for ; Sat, 14 Sep 2019 12:19:39 -0700 (PDT) X-Received: by 2002:a2e:814d:: with SMTP id t13mr34140740ljg.72.1568488779341; Sat, 14 Sep 2019 12:19:39 -0700 (PDT) MIME-Version: 1.0 References: <20190910173243.GA3992@darwi-home-pc> <20190911160729.GF2740@mit.edu> <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> <214fed0e-6659-def9-b5f8-a9d7a8cb72af@gmail.com> <8c2a47cc-a519-ad94-5d9a-18bb03ba2fd7@gmail.com> In-Reply-To: <8c2a47cc-a519-ad94-5d9a-18bb03ba2fd7@gmail.com> From: Linus Torvalds Date: Sat, 14 Sep 2019 12:19:23 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Linux 5.3-rc8 To: "Alexander E. Patrakov" Cc: "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, Lennart Poettering , lkml 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 Sat, Sep 14, 2019 at 10:09 AM Alexander E. Patrakov wrote: > > > Which means that we're all kinds of screwed. The whole "we guarantee > > entropy" model is broken. > > I agree here. Given that you suggested "to just fill the buffer and > return 0" in the previous mail (well, I think you really meant "return > buflen", otherwise ENOENTROPY == 0 and your previous objection applies), Right. The question remains when we should WARN_ON(), though. For example, if somebody did save entropy between boots, we probably should accept that - at least in the sense of not warning when they then ask for randomness data back. And if the hardware does have a functioning rdrand, we probably should accept that too - simply because not accepting it and warning sounds a bit too annoying. But we definitely *should* have a warning for people who build embedded devices that we can't see any reasonable amount of possible entropy. Those have definitely happened, and it's a serious and real security issue. > let's do just that. As a bonus, it saves applications from the complex > dance with retrying via /dev/urandom and finally brings a reliable API > (modulo old and broken kernels) to get random numbers (well, as random > as possible right now) without needing a file descriptor. Yeah, well, the question in the end always is "what is reliable". Waiting has definitely not been reliable, and has only ever caused problems. Returning an error (or some status while still doing a best effort) would be reasonable, but I really do think that people will mis-use that. We just have too much of a history of people having the mindset that they can just fall back to something better - like waiting - and they are always wrong. Just returning random data is the right thing, but we do need to make sure that system developers see a warning if they do something obviously wrong (so that the embedded people without even a real-time clock to initialize any bits of entropy AT ALL won't think that they can generate a system key on their router). Linus