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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,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 39BF3C3A5A2 for ; Fri, 20 Sep 2019 18:29:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 19BF52070C for ; Fri, 20 Sep 2019 18:29:58 +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="okqPnLwc" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2436476AbfITS35 (ORCPT ); Fri, 20 Sep 2019 14:29:57 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:39584 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2406366AbfITS34 (ORCPT ); Fri, 20 Sep 2019 14:29:56 -0400 Received: by mail-pf1-f196.google.com with SMTP id v4so442208pff.6 for ; Fri, 20 Sep 2019 11:29:56 -0700 (PDT) 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=su37uabqeDyNPGVbSy4LqMylRvJekDBMIJQOmAbSrms=; b=okqPnLwcRVFAFawtFpNAsOM/l6PAjdVUI4aWBFLH6PcKUlwJPqfVibKuhiLaiEvyjX YF3vdcFzm7VQGbWu8A1tmTfWurx0OPEZRuO0HCKGaCCaas0wF0nNqk71cq8AmBT9tCfv cvAI8wimfyvmpY7+b9mDlhkTr+z95vp6N7iSCSpPu9L+UbGYirqBsaMxfA6CpV7EqYvi g7IgYjddC3+CAWtIVG2TORJCXBBiZL0DUy1lNplzldwBX8vlKQ12d5acnX5K/atIF2cg 16Suk191AECRxh3jGrkh/Gm7hxi1wY7zn0I2TfuJYtkDAo33tKLNzHxAThuUFgY3qINM xLpA== 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=su37uabqeDyNPGVbSy4LqMylRvJekDBMIJQOmAbSrms=; b=eevJ5yFywnbX9KwjQFEXWmWXgl3rqqPUHnMuLP9AXgW0vnjTizr52w2dalQ+djoMOW lpJd81oqnQ6CcUifTDN6fdqkpGLBaLP6pcrnsR9lzOuaACZ62btX4pUy82It+t9AMX4y OcWxu/gMIkQ1JDTVgaGnhMhee+hBM55AhHY7wGjSdubV7mcNA+oTJnZyoCox91DckvIw kJtQMdq5UKAq23Q1mlhE0m9jpRLOVGyPkewvVn5sfkR37F1cp9tl0lPz1tTXnF2gE8rb vmXRnvZPU7gkSGJpvoqtwqN26UGrcDT4BoDpS3XdZ099Ta8oCvM+Naj2ub65VwgmQAcf hLUg== X-Gm-Message-State: APjAAAVAQtOB1ESTozekEFz0u5kJySRRYg6h9GyQCPhF/MV7zValkp0B a6rFPAdn9+ygWgetoxJU+pgGYQ== X-Google-Smtp-Source: APXvYqw+IQcWT5VEowqn7ypP2rDJ8xYsWnAzjXoY3fTO9SwtB8M9afvxyLB0ZPbfNcYita9kGI3xpg== X-Received: by 2002:a62:1888:: with SMTP id 130mr19342667pfy.72.1569004195553; Fri, 20 Sep 2019 11:29:55 -0700 (PDT) Received: from ?IPv6:2600:1010:b006:e11f:c970:783e:78af:e8f5? ([2600:1010:b006:e11f:c970:783e:78af:e8f5]) by smtp.gmail.com with ESMTPSA id 74sm2391968pfy.78.2019.09.20.11.29.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 11:29:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Andy Lutomirski Mime-Version: 1.0 (1.0) Subject: Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2() Date: Fri, 20 Sep 2019 11:29:52 -0700 Message-Id: <7D3731D2-348F-4561-A52D-AA7DAAEE258B@amacapital.net> References: <78a4b774-ef6b-62cb-57db-8e1ff8d29f72@gmail.com> Cc: Andy Lutomirski , Linus Torvalds , "Ahmed S. Darwish" , Lennart Poettering , "Theodore Y. Ts'o" , "Eric W. Biederman" , Michael Kerrisk , Willy Tarreau , Matthew Garrett , lkml , Ext4 Developers List , Linux API , linux-man In-Reply-To: <78a4b774-ef6b-62cb-57db-8e1ff8d29f72@gmail.com> To: "Alexander E. Patrakov" X-Mailer: iPhone Mail (17A577) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Sep 20, 2019, at 11:15 AM, Alexander E. Patrakov w= rote: >=20 > =EF=BB=BF20.09.2019 22:52, Andy Lutomirski =D0=BF=D0=B8=D1=88=D0=B5=D1=82:= >> I think that, given existing software, we should make two or three >> changes to fix the basic problems here: >> 1. Add GRND_INSECURE: at least let new applications do the right thing >> going forward. >> 2. Fix what is arguably a straight up kernel bug, not even an ABI >> issue: when a user program is blocking in getrandom(..., 0), the >> kernel happily sits there doing absolutely nothing and deadlocks the >> system as a result. This IMO isn't an ABI issue -- it's an >> implementation problem. How about we make getrandom() (probably >> actually wait_for_random_bytes()) do something useful to try to seed >> the RNG if the system is otherwise not doing IO. >> 3. Optionally, entirely in user code: Get glibc to add new *library* >> functions: getentropy_secure_blocking() and getentropy_insecure() or >> whatever they want to call them. Deprecate getentropy(). >> I think #2 is critical. Right now, suppose someone has a system that >> neets to do a secure network request (a la Red Hat's Clevis). I have >> no idea what Clevis actually does, but it wouldn't be particularly >> crazy to do a DH exchange or sign with an EC key to ask some network >> server to help unlock a dm-crypt volume. If the system does this at >> boot, it needs to use getrandom(..., 0), GRND_EXPLICIT, or whatever, >> because it NEEDS a secure random number. No about of ABI fiddling >> will change this. The kernel should *work* in this case rather than >> deadlocking. >=20 > Let me express a little bit of disagreement with the logic here. >=20 > I do agree that #2 is critical, and the Clevis use case is a perfect examp= le why it is important. I doubt that it is solvable without trusting jitter e= ntropy, or without provoking a dummy read on a random block device, just for= timings, or maybe some other interaction with the external world - but Will= y already said "it seems fishy". However, _if_ it is solved, then we don't n= eed GRND_INSECURE, because solving #2 is equivalent to magically making secu= re random numbers always available. >=20 >=20 I beg to differ. There is a big difference between =E2=80=9Cdo your best *ri= ght now*=E2=80=9D and =E2=80=9Cgive me a real secure result in a vaguely tim= ely manner=E2=80=9D. For example, the former is useful for ASLR or hash table randomization. The l= atter is not.=