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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 85090C43334 for ; Fri, 22 Jul 2022 11:23:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=AqvWKC5RbOfu9i+sbAEKXRRPX4tihOUANWFHUHf0H2k=; b=lnF0DF0UsbJXd3 7XMCShJc5HmSAylVA/3p0Mm66yn04ZoLwQ2m2bPRQ/CzELf+Z4UCyKfWghssBuAiXOKQi47juk/UY p7MrA8JjOrfmcHGez2FFMF9WQou2B0vwJeqPwwB9unkopq7hG6hUJoqleKYs13+4ShLSrw45rtQzr aMrWU5DaYDUKgjkdb0dzWZ4RVsPs2zGHnz/AGLO6rUD2tjEwBa+eiIxZm9FT4q0B85j4o9wY0Iqij 16yO6vKhkJ+l7ifagF3Xdv3/LvSINEL6lAPSB8HIkb9+jE5U0TdH/77QID7SMXvflB7Olvguqdk+B SmQyE6SRGtcrsYaRsZzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEqjq-003NGj-Kk; Fri, 22 Jul 2022 11:22:34 +0000 Received: from dfw.source.kernel.org ([2604:1380:4641:c500::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEqjn-003NEI-Fu for linux-arm-kernel@lists.infradead.org; Fri, 22 Jul 2022 11:22:33 +0000 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 dfw.source.kernel.org (Postfix) with ESMTPS id 66BAA61944; Fri, 22 Jul 2022 11:22:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DE79C341C6; Fri, 22 Jul 2022 11:22:27 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="A72kHDjI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1658488946; 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=tEMNMB2Z49B1S8tRR73A3k1qlwc8qZ7y2Lb47TLNcJY=; b=A72kHDjIhCKy1SCFFNVSX+Vp2BEvkV7ka1UD5j32SfhxQnO0X7LJ74HcDr+imBz9vI5rhm 6080JFv+KzAAK4056Y1qyXv5he1wWynhSKqQTQdQz1e06bV9uLXXkXAsiCX/HmW32WQCQu qilfUhpkwlG/HTO/fr6WxsF3nMcVXzM= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 18cc06f4 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 22 Jul 2022 11:22:26 +0000 (UTC) Date: Fri, 22 Jul 2022 13:22:22 +0200 From: "Jason A. Donenfeld" To: Holger Dengler 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 , Michael Ellerman , Alexander Gordeev , Thomas Gleixner , "H . Peter Anvin" , Catalin Marinas , Borislav Petkov , Heiko Carstens , Johannes Berg , Harald Freudenberger Subject: Re: [PATCH v2] random: handle archrandom in plural words Message-ID: References: <20220717200356.75060-1-Jason@zx2c4.com> <46c1a7be-080b-3315-50cc-d3c848fd99e3@linux.ibm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <46c1a7be-080b-3315-50cc-d3c848fd99e3@linux.ibm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220722_042231_870291_65D1D057 X-CRM114-Status: GOOD ( 20.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Holger, On Fri, Jul 22, 2022 at 10:08:05AM +0200, Holger Dengler wrote: > Why not changing the API to take bytes instead of words? Sure, at the > moment it looks like all platforms with TRNG support are able to > deliver at least one word, but bytes would be more flexible. The idea is to strike a sweet spot between capabilities. S390x is fine with byte-level granularity up to arbitrary lengths, while x86 is best with word-level granularity of length 1. The happy intersection between the two is just word-level granularity of arbitrary length. Yes we _could_ introduce a lot of code complexity by cascading the x86 case down into smaller and smaller registers, ignoring the fact that it's no longer efficient below 32- or 64-bit registers depending on vendor. But then we're relying on the inliner to remove all of that extra code, since all callers actually only ever want 32 or 64 bytes. Why bloat for nothing? The beauty of this approach is that it translates very naturally over all the various quirks of architectures without having to have a lot of coupling code. The other reason is that it's simply not necessary. The primary use for this in random.c is to fill a 32- or 64-*byte* block with "some stuff", preferring RDSEED, then RDRAND, and finally falling back to RDTSC. These correspond with arch_get_random_seed_longs(), arch_get_random_longs(), and random_get_entropy() (which is usually get_cycles() underneath), respectively. With the cycle counter being (at least) ~word-sized on all platforms, keeping the granularity of the arch_get_random_*_longs() functions the same lets us fill these with a basic cascade that doesn't require a lot of code: 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(); } By using a word as the underlying unit, the above cascade generates optimal code on basically all archrandom platforms, no matter what their byte-vs-word or one-vs-three-vs-many semantics are. That's a bit long winded, but hopefully that gives a bit of insight on why going from _long -> _longs is so "lazy" looking. Jason _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel