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.5 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 60CD9C4CEC7 for ; Sun, 15 Sep 2019 10:40:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FE732077C for ; Sun, 15 Sep 2019 10:40:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728791AbfIOKkv (ORCPT ); Sun, 15 Sep 2019 06:40:51 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:45192 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725613AbfIOKkv (ORCPT ); Sun, 15 Sep 2019 06:40:51 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8FAeRui021844; Sun, 15 Sep 2019 12:40:27 +0200 Date: Sun, 15 Sep 2019 12:40:27 +0200 From: Willy Tarreau To: "Ahmed S. Darwish" Cc: Lennart Poettering , "Theodore Y. Ts'o" , Linus Torvalds , "Alexander E. Patrakov" , Michael Kerrisk , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: [PATCH RFC v3] random: getrandom(2): optionally block when CRNG is uninitialized Message-ID: <20190915104027.GG20811@1wt.eu> 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> <20190915081747.GA1058@darwi-home-pc> <20190915085907.GC29771@gardel-login> <20190915093057.GF20811@1wt.eu> <20190915100201.GA2663@darwi-home-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190915100201.GA2663@darwi-home-pc> 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 Sun, Sep 15, 2019 at 12:02:01PM +0200, Ahmed S. Darwish wrote: > On Sun, Sep 15, 2019 at 11:30:57AM +0200, Willy Tarreau wrote: > > On Sun, Sep 15, 2019 at 10:59:07AM +0200, Lennart Poettering wrote: > > > We live in a world where people run HTTPS, SSH, and all that stuff in > > > the initrd already. It's where SSH host keys are generated, and plenty > > > session keys. > > > > It is exactly the type of crap that create this situation : making > > people developing such scripts believe that any random source was OK > > to generate these, and as such forcing urandom to produce crypto-solid > > randoms! > > Willy, let's tone it down please... the thread is already getting a > bit toxic. I don't see what's wrong in my tone above, I'm sorry if it can be perceived as such. My point was that things such as creating lifetime keys while there's no entropy is the wrong thing to do and what progressively led to this situation. > > > If Linux lets all that stuff run with awful entropy then > > > you pretend things where secure while they actually aren't. It's much > > > better to fail loudly in that case, I am sure. > > > > This is precisely what this change permits : fail instead of block > > by default, and let applications decide based on the use case. > > > > Unfortunately, not exactly. > > Linus didn't want getrandom to return an error code / "to fail" in > that case, but to silently return CRNG-uninitialized /dev/urandom > data, to avoid user-space even working around the error code through > busy-loops. But with this EINVAL you have the information that it only filled the buffer with whatever it could, right ? At least that was the last point I manage to catch in the discussion. Otherwise if it's totally silent, I fear that it will reintroduce the problem in a different form (i.e. libc will say "our randoms are not reliable anymore, let us work around this and produce blocking, solid randoms again to help all our users"). > I understand the rationale behind that, of course, and this is what > I've done so far in the V3 RFC. > > Nonetheless, this _will_, for example, make systemd-random-seed(8) > save week seeds under /var/lib/systemd/random-seed, since the kernel > didn't inform it about such weakness at all.. Then I am confused because I understood that the goal was to return EINVAL or anything equivalent in which case the userspace knows what it has to deal with :-/ Regards, Willy