Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp4573315ybe; Mon, 16 Sep 2019 14:43:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqynvVu1RAKAa1ZI3jNrRc9YfCnenWBFfTB6R30ZLR84L9XElpC+8VD6EuPHmx5Ju+odKQq3 X-Received: by 2002:a50:d51b:: with SMTP id u27mr1425733edi.249.1568670210179; Mon, 16 Sep 2019 14:43:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568670210; cv=none; d=google.com; s=arc-20160816; b=PifKud2tzyuX0Wi28Ub8m+QMXZpbqbkIZcn734JpnToTzi40P7Ydjo4OGXpNS5dxMD L9gLvlKJo9e8JHbC7xdrwbjLk8m5laDrDT1H8jJmfC3vZcuQ/7nKZmeigtuae5m7rhPf hyV2NI+UUIcSKOMCRi9kuAOa88utR4i+5tp+GQNIiBnTwERUlza1XM/7ITwf4/VKGtYp 4pA5k/ZhfXOtvtq/9lmHm9KLNHRPykMK/JfCNfRwRraRPWNWwkj3DtqvUZRNCupeEKHT 0xqR+qucFPXZNMp3gcnOQAksxyYEdQkooUFax+VNSQPFIANaBe1rkKY6SXwBASBdTf7w lzOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=kWJ7wiYHscdnK9jvZugixHM2oOtVuncWX/56fhAI0zA=; b=vt3v5t7cSQC0C7EGwH1nceYmdlz/TNkfjHP3pMI/xqkPpJH3+K4adHgUWGe8dFY3ji A7dfJ7np3O/GuXqiBhzi6Mqq+Pcyziko4K2OApUsKJTd7X98OLToD+iU8r2hPa3g/cFM sCyN6sk6xp5OeZLaEiVkX8+EU97KYcLrSPmAJbqbL9QCfxNJj9MivMZ+TqSt/hZ0Iby/ B8QThSyd769thF8By12DktcEsTQ5qeT37IcY773kC8krjF3uSrKKGvp+6mabICG0j3gT la1p0rk0rQHAwWAgYidGXsYbYgAvlEOtV+wuDCGCaEpFq1Kc6aYovlEz1rIMIGdGbSLR zU/A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pg17si91825ejb.288.2019.09.16.14.43.05; Mon, 16 Sep 2019 14:43:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-ext4-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728010AbfIPTQf (ORCPT + 99 others); Mon, 16 Sep 2019 15:16:35 -0400 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:46291 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725912AbfIPTQf (ORCPT ); Mon, 16 Sep 2019 15:16:35 -0400 Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id x8GJGFgj025977; Mon, 16 Sep 2019 21:16:15 +0200 Date: Mon, 16 Sep 2019 21:16:15 +0200 From: Willy Tarreau To: Lennart Poettering Cc: Linus Torvalds , "Theodore Y. Ts'o" , "Alexander E. Patrakov" , "Ahmed S. Darwish" , Michael Kerrisk , Andreas Dilger , Jan Kara , Ray Strode , William Jon McCann , zhangjs , linux-ext4@vger.kernel.org, lkml Subject: Re: [PATCH RFC v2] random: optionally block in getrandom(2) when the CRNG is uninitialized Message-ID: <20190916191615.GE24547@1wt.eu> References: <20190911173624.GI2740@mit.edu> <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> <20190916180801.GB30990@gardel-login> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190916180801.GB30990@gardel-login> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Mon, Sep 16, 2019 at 08:08:01PM +0200, Lennart Poettering wrote: > I mean, as I understand you are unhappy with behaviour you saw on > systemd systems; we can certainly improve behaviour of systemd in > userspace alone, i.e. abort the getrandom() after a while in userspace > and log about it using typical userspace logging to the console. I am > not sure why you want to do all that in the kernel, the kernel isn't > great at user interaction, and really shouldn't be. Because the syscall will have the option to return what random data was available in this case, while if you try to fix it only from within systemd you currently don't even get that data. > It appears to me you subscribe too much to an idea that userspace > people are not smart enough and couldn't implement something like > this. Turns out we can though, and there's no need to add logic that > appears to follow the logic of "never trust userspace"... I personally see this very differently. If randoms were placed into a kernel compared to other operating systems doing everything in userspace, it's in part because it requires to collect data very widely to gather some entropy and that no isolated userspace alone can collect as much as the kernel. Or they each have to reimplement their own method, each with their own bugs, instead of fixing them all at a single place. All applications need random, there's no reason for having to force them all to implement them in detail. Willy