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.2 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 06272C88CAB for ; Mon, 23 Sep 2019 20:49:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D395421655 for ; Mon, 23 Sep 2019 20:49:58 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2502528AbfIWUtu (ORCPT ); Mon, 23 Sep 2019 16:49:50 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.26.193]:38778 "EHLO atrey.karlin.mff.cuni.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389848AbfIWUtu (ORCPT ); Mon, 23 Sep 2019 16:49:50 -0400 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 512) id C47F88062D; Mon, 23 Sep 2019 22:49:31 +0200 (CEST) Date: Mon, 23 Sep 2019 22:49:45 +0200 From: Pavel Machek 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, Lennart Poettering , lkml Subject: chaos generating driver was Re: Linux 5.3-rc8 Message-ID: <20190923204944.GA1107@bug> 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: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Hi! > > => 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. Hmm. This actually points to a solution, and I believe solution is in the kernel. Userspace is not the best place to decide what is the best way to generate entropy. > As mentioned, this has already historically been a huge issue on > embedded devices, and with disks turnign not just to NVMe but to > actual polling nvdimm/xpoint/flash, the amount of true "entropy" > randomness we can give at boot is very questionable. > > We can (and will) continue to do a best-effort thing (including very > much using rdread and friends), but the whole "wait for entropy" > simply *must* stop. And we can stop it... from kernel, and without hacks. Simply by generating some entropy. We do not need to sit quietly while userspace waits for entropy to appear. We can for example do some reads from the disk. (find / should be good for generating entropy on many systems). For systems with rtc but not timestamp counter, we can actually just increase register, then read it from interrupt... ...to get precise timings. We know system is blocked waiting for entropy, we can do expensive things we would not "normally" do. Yes, it would probably mean new kind of "driver" whose purpose is to generate some kind of activity so that interrupts happen and entropy is generated... But that is still better solution than fixing all of the userspace. (With some proposals here, userspace _could_ do while (getrandom() == -EINVAL) { system("find / &"); sleep(1); } ...but I believe we really want to do it once, in kernel, and less hacky than this) Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html