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=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MIME_QP_LONG_LINE, 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 94B7CC2D0DA for ; Thu, 26 Dec 2019 11:12:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5745A2075E for ; Thu, 26 Dec 2019 11:12:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="Qrbad0eH" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726277AbfLZLMe (ORCPT ); Thu, 26 Dec 2019 06:12:34 -0500 Received: from mail-pg1-f194.google.com ([209.85.215.194]:35343 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726236AbfLZLMe (ORCPT ); Thu, 26 Dec 2019 06:12:34 -0500 Received: by mail-pg1-f194.google.com with SMTP id l24so12733715pgk.2 for ; Thu, 26 Dec 2019 03:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=XahL6G9knLB2n8H5gfpDsu6npK96lVW0v/QhI2IvksY=; b=Qrbad0eHXMsPnR+ep/hgorsJ3L6/UQ2sMmnCFfDyOrsAH9gmPzUE+O/ihf8HbpmSe2 XTzrt9NI9JS19AC2ejj62s6PJlqoV8uEkFI6B2EUziulBKnZacCpUAk85XIlOhuzwMod D2tJwuBtOKf6P6HWIp5IpVYx4zNvJMzTfIKblwY7wVhh16qcybT6pCb5d0nslb/ieDbZ u7ZkEeLPc4fuRT/8CZVYGWqVevBDB0co3tPF0ysPnFICrBTzawoFWnKIQwrRqnfbdaRN IKRYrNAXBxkF4wJNOjgBlxATJdf+ezJg0aMV4/CDo0nSqMEOnkf5Ory2Qm5ImGL5PdS1 Yunw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=XahL6G9knLB2n8H5gfpDsu6npK96lVW0v/QhI2IvksY=; b=h7nrIqs+wItflLi76U+br+Y9XSPCGR5WKPPdZDvNeCGXovR3mC+oC7u6MMD+MQPNCd B6QlpTNgihXol1zMVs7tLx0Mz9nHxbAVOtAQHMu4HGp1l1IeaNWnrDq4PGGD39qlU95V YNEkkDixq/05x5L4+gLtcsCQXZL5EmMZYw8KGWugMDoyw5IdE1TksUJL/zDKlZ4x95HV rU+7khYN4rqlKC1rlKtkK3iMgQ/fobYznRxaEz96dJFaA0qtuYdsJEcShvXq/QygZBqu HCPaP5T6juNEnxle25aEvcxXBH6dPi6SsC2RHuwozpgRrh0hzeNTsYg7ayiLASDeTegO b4QA== X-Gm-Message-State: APjAAAWaMTwmegP4U4vqL9zF+R0ZffRBbB5d0Vc5V4YTzebIfAHa7+b7 RDYDaIJcANzwNHROeuZ39zNSZA== X-Google-Smtp-Source: APXvYqxMxc1hyWglZzwXvoW3reh+R+YzQsWl78Yfn6rauhrZAzzQW2YTb57MMRoRZn12XDGrddKtpA== X-Received: by 2002:a63:ff20:: with SMTP id k32mr46522975pgi.448.1577358753722; Thu, 26 Dec 2019 03:12:33 -0800 (PST) Received: from [25.170.118.188] ([172.58.27.172]) by smtp.gmail.com with ESMTPSA id i3sm34346841pfo.72.2019.12.26.03.12.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 26 Dec 2019 03:12:32 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v3 0/8] Rework random blocking Date: Thu, 26 Dec 2019 19:12:29 +0800 Message-Id: <888017FA-06A1-42EF-9FC0-46629138DA9E@amacapital.net> References: <9872655.prSdhymlXK@positron.chronox.de> Cc: Andy Lutomirski , Ted Ts'o , 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 In-Reply-To: <9872655.prSdhymlXK@positron.chronox.de> To: =?utf-8?Q?Stephan_M=C3=BCller?= X-Mailer: iPhone Mail (17C54) Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org > On Dec 26, 2019, at 5:29 PM, Stephan M=C3=BCller wro= te: >=20 > =EF=BB=BFAm Montag, 23. Dezember 2019, 09:20:43 CET schrieb Andy Lutomirsk= i: >=20 > Hi Andy, >>=20 >> There are some open questions and future work here: >>=20 >> 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. >=20 > What about offering a compile-time option to enable or disable such code? > Note, with the existing random.c code base, there is no need to have a=20 > separate blocking_pool. The ChaCha20 DRNG could be used for that very same= =20 > purpose, provided that in case these true random numbers are generated whe= n=20 > the Chacha20 DRNG received an equal amount of "unused" entropy. This scares me. The DRNG should be simple and easy to understand. If we=E2=80= =99re tapping extra numbers in some weird way, then I would be more comforta= ble with some clear assurance that this doesn=E2=80=99t break the security. I= f we=E2=80=99re tapping numbers in the same way as normal urandom, then I do= n=E2=80=99t really see the point. >>=20 >> 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. >=20 > With the patch set v26 of my LRNG I offer another possible alternative=20 > avoiding any additional character device file and preventing the starvatio= n of=20 > legitimate use cases: the LRNG has an entropy pool that leaves different=20= > levels of entropy in the pool depending on the use cases of this data. >=20 > If an unprivileged caller requests true random data, at least 1024 bits of= =20 > entropy is left in the pool. I.e. all entropy above that point is availabl= e=20 > for this request type. Note, even namespaces fall into this category=20 > considering that unprivileged users can create a user name space in which t= hey=20 > can become root. This doesn=E2=80=99t solve the problem. If two different users run stupid pr= ograms like gnupg, they will starve each other. As I see it, there are two major problems with /dev/random right now: it=E2=80= =99s prone to DoS (i.e. starvation, malicious or otherwise), and, because no= privilege is required, it=E2=80=99s prone to misuse. Gnupg is misuse, full s= top. If we add a new unprivileged interface, gnupg and similar programs will= use it, and we lose all over again.