Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp2555810ybl; Thu, 9 Jan 2020 15:03:54 -0800 (PST) X-Google-Smtp-Source: APXvYqxxOKl8+oFESMAuf45eKmypIYNXkE+h8TSWwJzwbyPE7vySsgrWot1fS4U0L067klZwXzzU X-Received: by 2002:a05:6808:8ca:: with SMTP id k10mr4954657oij.164.1578611034438; Thu, 09 Jan 2020 15:03:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1578611034; cv=none; d=google.com; s=arc-20160816; b=XDVE3cp7YPgzSnDmDmlPo2DwWa7uIQQqG1X+WVB3CXMX/mfvDXPLseTpD5ldAH3EST bhsaylpnkPmVPxCcDgr1pcj7FLUkGWmBL5qkkfnrCIB7iGzyo/+UUMHO3mbONDTDrL/h DXKF5NOgs01HJ0K6WqhhXy5GKLiEAZaLpArwDXLCvPNNWj0yLwOyeFRdo6K3GwRm/hJd L9feFiG14pWX/lt+D9yKsQaJ9h9Wo5Mxz7HuRspZ/9zALqZZa59PvaT0cmjDq/P7CkqJ A6KX0b40xv9VXYZSWbjXiUtWHdrI2LlD4UKR0Xwul3O+6S/H5qwycmIsDfXqAekhS9JP Q2fQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=6KzVuLyeDfj6/EHNdamUnPO/ZiKnKOs2MqEOD8IIvvE=; b=kz/EV6hqKek0ezWj6yIFe13poKfXDf62zPS0tXoV+ZZcBOsNcGpRlpQv2X67YLGRvf q5HK4+PNjltGjs3L/LxUoJzCcgy+MUtg9w1xoKgVhUMGUdxtMV5gMuFIC/cymNO8bIu7 OorBkmEKkFFfj1NhgwhcBRu5K+jq7HYynBm79NR0bgr1W5A/yplSEpVsWjjDJ1Z/Zg3m wqQRJjwSuyNiLsCbe3QD5m+PnpEHRGTZa+YPobRbILv/XV5pV5MpDpX3TmiRNx20LRHR ek91WoJEXb5mxpReGrgOv43vQL5jcG/2YqWYKIbAvhB03yBxhBRQuBbqw16+G9AL//nb IcCg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=roeckx.be Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3si10981otz.198.2020.01.09.15.03.33; Thu, 09 Jan 2020 15:03:54 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=roeckx.be Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728508AbgAIXCl (ORCPT + 99 others); Thu, 9 Jan 2020 18:02:41 -0500 Received: from excelsior.roeckx.be ([195.234.45.115]:35675 "EHLO excelsior.roeckx.be" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726267AbgAIXCl (ORCPT ); Thu, 9 Jan 2020 18:02:41 -0500 Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 8B42EA8A0573; Thu, 9 Jan 2020 23:02:38 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 4C97F1FE0C7A; Fri, 10 Jan 2020 00:02:38 +0100 (CET) Date: Fri, 10 Jan 2020 00:02:37 +0100 From: Kurt Roeckx To: "Theodore Y. Ts'o" Cc: Stephan Mueller , Andy Lutomirski , Andy Lutomirski , 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 Subject: Re: [PATCH v3 0/8] Rework random blocking Message-ID: <20200109230237.GA2992@roeckx.be> References: <20191226140423.GB3158@mit.edu> <4048434.Q8HajmOrkZ@tauon.chronox.de> <20191227130436.GC70060@mit.edu> <15817620.rmTN4T87Wr@tauon.chronox.de> <20191227220857.GD70060@mit.edu> <20200109220230.GA39185@roeckx.be> <20200109224011.GD41242@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200109224011.GD41242@mit.edu> Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org On Thu, Jan 09, 2020 at 05:40:11PM -0500, Theodore Y. Ts'o wrote: > On Thu, Jan 09, 2020 at 11:02:30PM +0100, Kurt Roeckx wrote: > > > > One thing the NIST DRBGs have is prediction resistance, which is > > done by reseeding. If you chain DRBGs, you tell your parent DRBG > > that you want prediction resistance, so your parent will also > > reseed. There currently is no way to tell the kernel to reseed. > > It would be simple enough to add a new flag, perhaps GRND_RESEED, to > getrandom() which requests that the kernel reseed first. This would > require sufficient amounts of entropy in the input pool to do the > reseed; if there is not enough, the getrandom() call would block until > there was enough. If GRND_NONBLOCK is supplied, then getrandom() > would return EAGAIN if there wasn't sufficient entropy. > > Is this what you want? I think some people might want to see it, but I think you shouldn't add it. > > I don't think we want that. As far as I know, the only reason for > > using /dev/random is that /dev/urandom returns data before it > > has sufficient entropy. > > Is there any objections to just using getrandom(2)? It provides the interface we want, so no. But there are still people who don't have it for various reasons. OpenSSL actually does the system call itself if libc doesn't provider a wrapper for it. Kurt