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.0 required=3.0 tests=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 C34B2C4CEC6 for ; Sun, 15 Sep 2019 06:51:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9ECD7214AF for ; Sun, 15 Sep 2019 06:51:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727061AbfIOGvp (ORCPT ); Sun, 15 Sep 2019 02:51:45 -0400 Received: from gardel.0pointer.net ([85.214.157.71]:38242 "EHLO gardel.0pointer.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726259AbfIOGvp (ORCPT ); Sun, 15 Sep 2019 02:51:45 -0400 Received: from gardel-login.0pointer.net (gardel.0pointer.net [IPv6:2a01:238:43ed:c300:10c3:bcf3:3266:da74]) by gardel.0pointer.net (Postfix) with ESMTP id 502B3E81176; Sun, 15 Sep 2019 08:51:43 +0200 (CEST) Received: by gardel-login.0pointer.net (Postfix, from userid 1000) id C5A95160ADC; Sun, 15 Sep 2019 08:51:42 +0200 (CEST) Date: Sun, 15 Sep 2019 08:51:42 +0200 From: Lennart Poettering To: Linus Torvalds Cc: "Ahmed S. Darwish" , "Theodore Y. Ts'o" , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , "Alexander E. Patrakov" , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: Linux 5.3-rc8 Message-ID: <20190915065142.GA29681@gardel-login> References: <20190911160729.GF2740@mit.edu> <20190911173624.GI2740@mit.edu> <20190912034421.GA2085@darwi-home-pc> <20190912082530.GA27365@mit.edu> <20190914150206.GA2270@darwi-home-pc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sa, 14.09.19 09:30, Linus Torvalds (torvalds@linux-foundation.org) wrote: > > => src/random-seed/random-seed.c: > > /* > > * Let's make this whole job asynchronous, i.e. let's make > > * ourselves a barrier for proper initialization of the > > * random pool. > > */ > > k = getrandom(buf, buf_size, GRND_NONBLOCK); > > if (k < 0 && errno == EAGAIN && synchronous) { > > log_notice("Kernel entropy pool is not initialized yet, " > > "waiting until it is."); > > > > k = getrandom(buf, buf_size, 0); /* retry synchronously */ > > } > > Yeah, the above is yet another example of completely broken garbage. > > You can't just wait and block at boot. That is simply 100% > unacceptable, and always has been, exactly because that may > potentially mean waiting forever since you didn't do anything that > actually is likely to add any entropy. Oh man. Just spend 5min to understand the situation, before claiming this was garbage or that was garbage. The code above does not block boot. It blocks startup of services that explicit order themselves after the code above. There's only a few services that should do that, and the main system boots up just fine without waiting for this. Primary example for stuff that orders itself after the above, correctly: cryptsetup entries that specify /dev/urandom as password source (i.e. swap space and stuff, that wants a new key on every boot). If we don't wait for the initialized pool for cases like that the password for that swap space is not actually going to be random, and that defeats its purpose. Another example: the storing of an updated random seed file on disk. We should only do that if the seed on disk is actually properly random, i.e. comes from an initialized pool. Hence we wait for the pool to be initialized before reading the seed from the pool, and writing it to disk. I'd argue that doing things like this is not "garbage", like you say, but *necessary* to make this stuff safe and secure. And no, other stuff is not delayed for this (but there are bugs of course, some random services in 3rd party packages that set too agressive deps, but that needs to be fixed there, and not in the kernel). Anyway, I really don't appreciate your tone, and being sucked into messy LKML discussions. I generally stay away from LKML, and gah, you remind me why. Just tone it down, not everything you never bothered to understand is "garbage". And please don't break /dev/urandom again. The above code is the ony way I see how we can make /dev/urandom-derived swap encryption safe, and the only way I can see how we can sanely write a valid random seed to disk after boot. You guys changed semantics on /dev/urandom all the time in the past, don't break API again, thank you very much. Lennart