Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp6139370ybl; Mon, 23 Dec 2019 00:21:19 -0800 (PST) X-Google-Smtp-Source: APXvYqx6/5mQNa4bOc0FeB6Kt5qxTGLKx7XoNES6ES/txDjtt7VM16hJ/7/r7G+GuOcBQeCilWZP X-Received: by 2002:a9d:6d10:: with SMTP id o16mr32057919otp.28.1577089279456; Mon, 23 Dec 2019 00:21:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1577089279; cv=none; d=google.com; s=arc-20160816; b=Ei6k4RmMUpOy5F4O7Ep1ON4a470e6LEV38zBcaFFsS10zcdO7gciHQ3SEZ0X0x7cCM W2xpUwvH2cSJJcHFl1Sy3cZ67e13juYWmaCWO6rjVnfN/xqQxNFN0z/ssed5L8NJVjq9 NzJBOBNn51E9YdYIM7WyeNg9+u7a2cnmYy/BaM7YO9HOPs7srpmZg3awDeFORfQ2lUC7 rOoinF318f6544b3tFn7ruILbdSLksAtrh3qVPR+7Vd0VtUOE34LAF0jAlUtt9pDlAgL ZRVCq+uqYVHG5Rz/IETJQhkXYRO9GdqpOVhqMytONLhqMa3KsRhSKEXM3cCPjZrPZXbS 9BTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=cw9cEhnH6vFxRTDRnENgtX0ThkXNs2Y0pfGnm4uKXrk=; b=UfH3Zl9AWnjKNfJzsaNYx/esnayThxfvtxUxB1YcxQbGUJY/SOpOkOWT6wevEZvSHP qeHdysl3SIDfgvscXz7sBjeSda3kCbcwLeyj7G8S8pcAoiK6X+mqLdaz8N902Ve/IuHu wMyZlEP4U44esafdeR4ZvFgdoq7iMwRorvJwHDK/f5FEGayWpZQtJnmZcX4V6QO2tKSd fGx9vf8KWbOoeEZhpZwE2mvQTM+c+xCvwCpD5Ly0zNWD43Ig8HFJDIYFibrPUsSXsT9X vCHzVR5WFcac2KY3iag7ISmWABq0z+bjXT8WjaNJcKm+1SbhQ4YFiZLd6WBKBYxq0XT4 Qr+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="UNO/+6na"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d17si8872857oib.174.2019.12.23.00.21.01; Mon, 23 Dec 2019 00:21:19 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b="UNO/+6na"; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725901AbfLWIU7 (ORCPT + 99 others); Mon, 23 Dec 2019 03:20:59 -0500 Received: from mail.kernel.org ([198.145.29.99]:38512 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725855AbfLWIU7 (ORCPT ); Mon, 23 Dec 2019 03:20:59 -0500 Received: from localhost (36-236-5-169.dynamic-ip.hinet.net [36.236.5.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 93FF2206D3; Mon, 23 Dec 2019 08:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577089258; bh=p56QVij9RMXU1ekO5M0MbCScJhCEKQdVf0cDyyT/gqs=; h=From:To:Cc:Subject:Date:From; b=UNO/+6nadgj02xrLzwL1eLT2R0lROfKXyYj40CgCFsc6pasSd0w/wMe/hi/rCqYVP +5Uyfily1NngF/S1N12I+3LbDK2WCLkewGj79EnBX/kZ5+/MqVNtpCk5QBBDxU3KCy q3DzXR1yqlajygAzrmf9+gdCln1ac8K3MaJFFQs0= From: Andy Lutomirski To: Ted Ts'o Cc: LKML , Linux API , Kees Cook , "Jason A. Donenfeld" , "Ahmed S. Darwish" , Lennart Poettering , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Willy Tarreau , Matthew Garrett , Ext4 Developers List , linux-man , Stephan Mueller , Andy Lutomirski Subject: [PATCH v3 0/8] Rework random blocking Date: Mon, 23 Dec 2019 00:20:43 -0800 Message-Id: X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org This makes two major semantic changes to Linux's random APIs: It adds getentropy(..., GRND_INSECURE). This causes getentropy to always return *something*. There is no guarantee whatsoever that the result will be cryptographically random or even unique, but the kernel will give the best quality random output it can. The name is a big hint: the resulting output is INSECURE. The purpose of this is to allow programs that genuinely want best-effort entropy to get it without resorting to /dev/urandom. Plenty of programs do this because they need to do *something* during boot and they can't afford to wait. Calling it "INSECURE" is probably the best we can do to discourage using this API for things that need security. This series also removes the blocking pool and makes /dev/random work just like getentropy(..., 0) and makes GRND_RANDOM a no-op. I believe that Linux's blocking pool has outlived its usefulness. Linux's CRNG generates output that is good enough to use even for key generation. The blocking pool is not stronger in any material way, and keeping it around requires a lot of infrastructure of dubious value. This series should not break any existing programs. /dev/urandom is unchanged. /dev/random will still block just after booting, but it will block less than it used to. getentropy() with existing flags will return output that is, for practical purposes, just as strong as before. There are some open questions and future work here: Should the kernel provide an interface to get software-generated "true random" numbers? I can think of only one legitimate reason to use such an interface: compliance with government standards. If the kernel provides such an interface going forward, I think it should be a brand new character device, and it should have a default mode 0440 or similar. Software-generated "true random numbers" are a very limited resource, and resource exhaustion is a big deal. Ask anyone who has twiddled their thumbs while waiting for gnupg to generate a key. If we think the kernel might do such a thing, then patches 5-8 could be tabled for now. Alternatively, perhaps the kernel should instead provide a privileged interface to read out raw samples from the various entropy sources, and users who care could have a user daemon that does something intelligent with them. This would push the mess of trying to comply with whatever standards are involved to userspace. Userspace could then export "true randomness" via CUSE if it is so inclined, or could have a socket with a well-known name, or whatever else seems appropriate. I think that each available hwrng device should have its own character device, which will make it much easier to use sensibly from user mode. But I don't think this series needs to block on this. Changes from v2: - Fix some bugs in the conditions that cause warnings. Patch 2 is new. - Rebase to Linus' tree today. This didn't change anything. Changes from v1: - Rebased to v5.3. No other changes. Andy Lutomirski (8): random: Don't wake crng_init_wait when crng_init == 1 random: Add a urandom_read_nowait() for random APIs that don't warn random: Add GRND_INSECURE to return best-effort non-cryptographic bytes random: Ignore GRND_RANDOM in getentropy(2) random: Make /dev/random be almost like /dev/urandom random: Remove the blocking pool random: Delete code to pull data into pools random: Remove kernel.random.read_wakeup_threshold drivers/char/random.c | 245 +++++------------------------------- include/uapi/linux/random.h | 4 +- 2 files changed, 37 insertions(+), 212 deletions(-) -- 2.23.0