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, URIBL_BLOCKED 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 8E6D9C3A5A2 for ; Fri, 20 Sep 2019 19:52:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 603E220B7C for ; Fri, 20 Sep 2019 19:52:33 +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="m/Dmg/JW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729842AbfITTwc (ORCPT ); Fri, 20 Sep 2019 15:52:32 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:37966 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729830AbfITTwb (ORCPT ); Fri, 20 Sep 2019 15:52:31 -0400 Received: by mail-pg1-f196.google.com with SMTP id x10so4410065pgi.5 for ; Fri, 20 Sep 2019 12:52:31 -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=gcNXvtSyWvuQ5LByHh2uePUN26jQ3PokWQXYeNMdTRo=; b=m/Dmg/JW+4n89iQLkwR9YixMDIeVf27zFQCHMeU2vrr/Vf/mPOfxnNvPfe3OPGVCIb JgAPKsXQJhnD7tFI5MlKzN2xVjy8lP1etFfFQJ6uqTzpoQ2zt6AqXypDzmNHpc8wPlxV crjt8+KJWIThyAPCT4EQPrvHrdHbinVspic5j9BKz5RbkcHdT9crv3tv4qpn/aE9eA1n PMBQ0OAdva2QoUZMRO40b1D4dh+MZ0oPBPl/uwt1PjK41QI5n4GP65bK/tOOocfdaOPb fW7AswBfwe7B/XRzdJs+JsavsZIwjqyEid+QSgHJFI3Ye2MQDRaVklFCyYyobPXtLX0a K9pw== 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=gcNXvtSyWvuQ5LByHh2uePUN26jQ3PokWQXYeNMdTRo=; b=agmfGuKkvyKjMtOGaCyw28XqIcvLYIfSlbJ8cM5ErQbyxj6zAg19oyi7uB3BjsNnXQ 3cKj4PiZfeCz4kfsRL1RUp7VDncjHlDrhgtUV/uTxmcnc2s2nip1M7HrPQlsfWr30P+u L6JyMC5BowxGaHQ1eylOyUnHTL4RVA+Mg3a/xcz0vnnfANrxdRo3UwHV6MCUfcfw3rLx fabL6aqIBB/yKBpz/fjQAq6fPrqqFZWtd9A/w3JQT0GlQN/8JEeJJQ61tgTCaF2Y2oPR r+2MobcHL54bQaPlpaZpf6LMcu0x9kN5eStFQgWKE+Fd4V2gGXG9OzwF2dyUsHKB3lbx +wjQ== X-Gm-Message-State: APjAAAW7kRl+0PBwrLgjybqSqw0ba1dice1LML2bm22cwbJvjX7onZl5 UAsuPjVcK44vReUQvwRh++/o/Q== X-Google-Smtp-Source: APXvYqxtb4M5gtpX7qWD4dcjCAwsr874h41gGdjXYxHCsHqxUWbY1aFs2BvIpYyEDF4qF+PsPWIWvw== X-Received: by 2002:a62:cb:: with SMTP id 194mr20209663pfa.130.1569009150487; Fri, 20 Sep 2019 12:52:30 -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 c20sm5107273pfd.122.2019.09.20.12.52.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Sep 2019 12:52:29 -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 12:52:28 -0700 Message-Id: References: <20190920193740.GD1889@1wt.eu> Cc: Andy Lutomirski , Linus Torvalds , "Ahmed S. Darwish" , Lennart Poettering , "Theodore Y. Ts'o" , "Eric W. Biederman" , "Alexander E. Patrakov" , Michael Kerrisk , Matthew Garrett , lkml , Ext4 Developers List , Linux API , linux-man In-Reply-To: <20190920193740.GD1889@1wt.eu> To: Willy Tarreau X-Mailer: iPhone Mail (17A577) Sender: linux-man-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org > On Sep 20, 2019, at 12:37 PM, Willy Tarreau wrote: >=20 > =EF=BB=BFOn Fri, Sep 20, 2019 at 12:22:17PM -0700, Andy Lutomirski wrote: >> Perhaps userland could register a helper that takes over and does >> something better? >=20 > If userland sees the failure it can do whatever the developer/distro > packager thought suitable for the system facing this condition. >=20 >> But I think the kernel really should do something >> vaguely reasonable all by itself. >=20 > Definitely, that's what Linus' proposal was doing. Sleeping for some time > is what I call "vaguely reasonable". I don=E2=80=99t buy it. We have existing programs that can deadlock on boot.= Just throwing -EAGAIN at them in a syscall that didn=E2=80=99t previously b= lock does not strike me as reasonable. >=20 >> If nothing else, we want the ext4 >> patch that provoked this whole discussion to be applied, >=20 > Oh absolutely! >=20 >> which means >> that we need to unbreak userspace somehow, and returning garbage it to >> is not a good choice. >=20 > It depends how it's used. I'd claim that we certainly use randoms for > other things (such as ASLR/hashtables) *before* using them to generate > long lived keys thus we can have a bit more time to get some more > entropy before reaching the point of producing these keys. The problem is that we don=E2=80=99t know what userspace is doing with the o= utput from getrandom(..., 0), so I think we have to be conservative. New ker= nels need to work with old user code. It=E2=80=99s okay if they=E2=80=99re s= lower to boot than they could be. >=20 >> Here are some possible approaches that come to mind: >>=20 >> int count; >> while (crng isn't inited) { >> msleep(1); >> } >>=20 >> and modify add_timer_randomness() to at least credit a tiny bit to >> crng_init_cnt. >=20 > Without a timeout it's sure we'll still face some situations where > it blocks forever, which is the current problem. The point is that we keep the timer running by looping like this, which shou= ld cause add_timer_randomness() to get called continuously, which should pre= vent the deadlock. I assume the deadlock is because we go into nohz-idle an= d we sit there with nothing happening at all. >=20 >> Or we do something like intentionally triggering readahead on some >> offset on the root block device. >=20 > You don't necessarily have such a device, especially when you're > in an initramfs. It's precisely where userland can be smarter. When > the caller is sfdisk for example, it does have more chances to try > to perform I/O than when it's a tiny http server starting to present > a configuration page. What I mean is: allow user code to register a usermode helper that helps get= entropy. Or just convince distros to bundle some useful daemon that starts a= t early boot and lives in the initramfs.