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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 88E02C433EF for ; Mon, 25 Jul 2022 11:25:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235013AbiGYLZm (ORCPT ); Mon, 25 Jul 2022 07:25:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234703AbiGYLZj (ORCPT ); Mon, 25 Jul 2022 07:25:39 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E9BD13F9A; Mon, 25 Jul 2022 04:25:38 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 0AD2F2005D; Mon, 25 Jul 2022 11:25:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1658748337; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j/9WpKQ5QRClT7V7QGV66k1XiLQwCz29JU6f+PwSms0=; b=vi0ewQ2zMuHdDXWDXkxY4Z8OFRChESV8dWBtQRzR57H+dvD1TuDR0AbNqSzvb+zyJWnUMi IdY7qN3loqmmaycThy99JASd+S9BRzPI7SlBd7VlYEQz75cz6kzlUfiSFp+Xfwz4x5WZHS NKYjNv+1Fbl7kQy5zoDSpDqmakaB9X0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1658748337; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j/9WpKQ5QRClT7V7QGV66k1XiLQwCz29JU6f+PwSms0=; b=bcug884lC8Iy4aI8HxMtEHjkxobfKamSnFyZxNcVCZlaqgLZUufdinpWxmolPhaC++vbxQ 0xmUfO2USHdIuxBw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id F0CBD13ABB; Mon, 25 Jul 2022 11:25:36 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id EGvHOrB93mKhRQAAMHmgww (envelope-from ); Mon, 25 Jul 2022 11:25:36 +0000 Date: Mon, 25 Jul 2022 13:25:36 +0200 From: Borislav Petkov To: "Jason A. Donenfeld" 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 Content-Transfer-Encoding: 8bit In-Reply-To: <20220719130207.147536-1-Jason@zx2c4.com> Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On Tue, Jul 19, 2022 at 03:02:07PM +0200, Jason A. Donenfeld wrote: > The archrandom interface was originally designed for x86, which supplies > RDRAND/RDSEED for receiving random words into registers, resulting in > one function to generate an int and another to generate a long. However, > other architectures don't follow this. > > On arm64, the SMCCC TRNG interface can return between 1 and 3 longs. On > s390, the CPACF TRNG interface can return arbitrary amounts, with 32 > longs having the same cost as one. On UML, the os_getrandom() interface > can return arbitrary amounts. > > So change the api signature to take a "max_longs" parameter designating > the maximum number of longs requested, and then return the number of > longs generated. > > 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. Taken together, these two things > mean that the codegen doesn't really change much for one-word-at-a-time > platforms, while performance is greatly improved on platforms such as > s390. > > Cc: Will Deacon > Cc: Alexander Gordeev > Cc: Thomas Gleixner > Cc: H. Peter Anvin > Cc: Catalin Marinas > Cc: Borislav Petkov > Cc: Heiko Carstens > Cc: Johannes Berg > Cc: Mark Rutland > Cc: Harald Freudenberger > Acked-by: Michael Ellerman > Signed-off-by: Jason A. Donenfeld > --- > arch/arm64/include/asm/archrandom.h | 102 ++++++++++++-------------- > arch/arm64/kernel/kaslr.c | 2 +- > arch/powerpc/include/asm/archrandom.h | 30 ++------ > arch/powerpc/kvm/book3s_hv.c | 2 +- > arch/s390/include/asm/archrandom.h | 29 ++------ > arch/um/include/asm/archrandom.h | 21 ++---- > arch/x86/include/asm/archrandom.h | 41 +---------- > arch/x86/kernel/espfix_64.c | 2 +- > drivers/char/random.c | 45 ++++++++---- > include/asm-generic/archrandom.h | 18 +---- > include/linux/random.h | 12 +-- > 11 files changed, 116 insertions(+), 188 deletions(-) Acked-by: Borislav Petkov # for x86 Thx. -- Regards/Gruss, Boris. SUSE Software Solutions Germany GmbH GF: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)