Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp2582114imi; Mon, 25 Jul 2022 02:34:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sRwbuiK880T6G9y6Sgv2QYHpTEyisOu5gsAH6hHrD8etXvPyGWpO1cuikdyUP/Gf20jKhD X-Received: by 2002:a65:6907:0:b0:415:c9c1:eb4f with SMTP id s7-20020a656907000000b00415c9c1eb4fmr10331503pgq.193.1658741641166; Mon, 25 Jul 2022 02:34:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658741641; cv=none; d=google.com; s=arc-20160816; b=Hgn1vEWxAi7Q+pd0GKR5yzhmIjrzSMaFvcEd+SiMcnFq13qXQiylC3Kf6d+ZECsDX1 8Te8/HgHKcFNvlNHH3Hi+A8XefJEV57N7cHbAJYXBdCTpo11DQYL+l4sd6xTCm0bwqt6 lMMU3B35YM0NtzGYTYxu7u0kcWO+zQWn0fkgcHnn4wY5DYV+ywIdd6zpt07e+z8FoMxG zDALo21RZ2U4oFX65K3RX896C/QJyAzpdNbUqr/bdDILk45Oa28RJG0ec6DnoBlgpx5g yuLLhKqpo7tenh0jKsaBXYsPQ7cWzXo4sGqAJU7JECDICvTdGFJrPWl14MZN/OVGW/i3 XRZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=zvNrHbTIYzgB0tkOGhVVxAdAHnHebTQeizi3weVIsK0=; b=WWZUmNm4rEiMJlwAqvazGTeWg5dVQX8marDCvbffFz81KbICuxX3aLucPPuuJbP0Ei 4VUQCh5crC/bGuHQek2U3enYjPrC8i8jak5D18OW9ujiYuiJWIe3WmJa//plLNlyTZBT eVMrMv+35uup7lF5lb9dzfcTk133gPF5vi8EAxNSd8SBttMTtCCLfJvD0Ehg+3EPyVgZ 60LSwetpYO0SI/ZjTTcqaQByKSQGO8wDxCnHj2VUb9t+vlu1KTCqdUBcaf+jZ8CvXHXB 0zQ0hznTsg2f9n30A43DOQFVYNKr2oP6EDm1nKKWXjPcXx6MhF74ingOhx4evLniA1XP usEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=LZX4uVNM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j64-20020a638b43000000b00419e5f32d92si13737279pge.138.2022.07.25.02.33.46; Mon, 25 Jul 2022 02:34:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=LZX4uVNM; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=zx2c4.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233335AbiGYJ0j (ORCPT + 99 others); Mon, 25 Jul 2022 05:26:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34772 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230192AbiGYJ0i (ORCPT ); Mon, 25 Jul 2022 05:26:38 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3704313CD3; Mon, 25 Jul 2022 02:26:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id EED06B80E19; Mon, 25 Jul 2022 09:26:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF553C341D2; Mon, 25 Jul 2022 09:26:32 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="LZX4uVNM" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1658741191; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zvNrHbTIYzgB0tkOGhVVxAdAHnHebTQeizi3weVIsK0=; b=LZX4uVNMACi/jB4HVvKJPq0/mnjxBgfqakoAfLysChDi3HgisD6QaHOYw75ZyyrX1xLahm XBKjHTCSVOHHHqTDjtlokbIDkMCdeoLQsma7KWe93PAIV8RSzydcGwPf7ehG3FWP89FhMN /bS3mQsDtxO03rpH0kQYPGkVIqqeD5I= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id d5a3a065 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Mon, 25 Jul 2022 09:26:30 +0000 (UTC) Date: Mon, 25 Jul 2022 11:26:27 +0200 From: "Jason A. Donenfeld" To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, x86@kernel.org, Will Deacon , Alexander Gordeev , Thomas Gleixner , "H . Peter Anvin" , Catalin Marinas , Heiko Carstens , Johannes Berg , Mark Rutland , Harald Freudenberger , Michael Ellerman Subject: Re: [PATCH v3] random: handle archrandom with multiple longs Message-ID: References: <20220719130207.147536-1-Jason@zx2c4.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Boris, On Mon, Jul 25, 2022 at 11:19:01AM +0200, Borislav Petkov wrote: > On Tue, Jul 19, 2022 at 03:02:07PM +0200, Jason A. Donenfeld wrote: > > Since callers need to check this return value and loop anyway, each arch > > implementation does not bother implementing its own loop to try again to > > fill the maximum number of longs. Additionally, all existing callers > > pass in a constant max_longs parameter. > > Hmm, maybe this has come up already but it reads weird. > > If I have a function arch_get_random_longs(), I'd expect it to give me > the number of longs I requested or say, error. > > Why do the callers need to loop? > > If I have to loop, I'd call the "get me one long" function and loop N > times. Answered partially in the commit message you quoted and partially here: https://lore.kernel.org/lkml/YtqIbrds53EuyqPE@zx2c4.com/ Note that arch_get_random_longs() is not a general purpose function. For that there used to be get_random_bytes_arch(), but that no longer exists as people shouldn't be using this stuff directly. arch_get_random_longs() is a special purpose function mainly intended for use by the RNG itself. More directly, the reason we don't want to error is because the use case has fallbacks meant to handle errors. The cascade looks like this (quoting from the other email): unsigned long array[whatever]; for (i = 0; i < ARRAY_SIZE(array);) { longs = arch_get_random_seed_longs(&array[i], ARRAY_SIZE(array) - i); if (longs) { i += longs; continue; } longs = arch_get_random_longs(&array[i], ARRAY_SIZE(array) - i); if (longs) { i += longs; continue; } array[i++] = random_get_entropy(); } It tries to get the best that it can as much as it can, but isn't going to block or do anything too nuts for that. Anyway, from an x86 perspective, I can't imagine you object to this change, right? Codegen is the same. Jason