Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1344829ybn; Wed, 25 Sep 2019 16:47:09 -0700 (PDT) X-Google-Smtp-Source: APXvYqyqhF5cGgBLG3tN5MMTPplePtbQ5GfJ6wDRmj0YK0eXMkW1+Wi7qJ24kkaPl7jcW6xuOlgS X-Received: by 2002:a17:906:34d0:: with SMTP id h16mr697657ejb.190.1569455229849; Wed, 25 Sep 2019 16:47:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569455229; cv=none; d=google.com; s=arc-20160816; b=M5FHQ8Q0x9h3ClqAHsa8nnnGsdKApZUZClLU8lKUDiBuvAZXJz+DiY1GlL2wKvm211 NAEC0gpiUBzCVK1nfSXJ6J28YRzkVOxY+0c5W0ezY+KQDNgRCwOofcYptCspdznf7zkJ 8VJAn0OqWneCoym+rjnioFO3UvFIH/Rw2bbkyEJKKSIckp4ADM8HN0PcTywGDPj0OODN Ti3a8hVL5PF/Fj7t2gESNhM5py9vIGu6SfqlD7bWL13/cIkaGL8ZBLcmT4wUzb7D0fCb zBCR7Xi/JwS6RDiS9LdR8gEPQ9n7QE3SeB5OnkgVgc4i8fhqC3LYBlD0KmCPnBrl464E 0IQw== 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=zqNsJ/FGCoEYTTyCNR67hXhshALan+k5Q7ovIttLSqE=; b=xA9o7BwR6ryj1E7vliTND74zISmcCze58BEW5zPEN4e1Fu5UF+2FfVhHopAI1uZnJ+ K5zOEW3h2fmqEQ9fSEiQ0ISGP0FTnQZD84tG860WyVZjQSANaGEErcQBDKj/oZUd/+/z qp8SLT/CTwzaxkrTPpGlqMCJnXvzDpyYAjDAo45qtpJDVVblAQ1QCBUTjDFeVbkzO2jW eCBT+hnTdc3keqAjPcRO9vewAAD4X5NV1v+0BMXCbSqkADAfZiqproKZgks1Tj2uECFU 9pI2PwvJJhTihBfVY22DBtCYXBF4fuQCT1KpS5PBmWkFCrLryiwjv9vPXf8eg4QJ2VXK ySpg== 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 r24si302581edy.417.2019.09.25.16.46.40; Wed, 25 Sep 2019 16:47:09 -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 S2502504AbfIWUtu (ORCPT + 99 others); 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 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