From patchwork Fri Apr 8 18:21:36 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807040 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 9498DC433EF for ; Fri, 8 Apr 2022 18:22:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238576AbiDHSYf (ORCPT ); Fri, 8 Apr 2022 14:24:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238550AbiDHSYY (ORCPT ); Fri, 8 Apr 2022 14:24:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5DBDB3713D9; Fri, 8 Apr 2022 11:22:20 -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 dfw.source.kernel.org (Postfix) with ESMTPS id DF72A6220B; Fri, 8 Apr 2022 18:22:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96822C385BB; Fri, 8 Apr 2022 18:22:15 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="jcpLG88Y" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442134; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bKnGziADgzlHYNafG897CPxh8A5i6JayWbcFusMVF+o=; b=jcpLG88YHHP6AloS0heU9nwr6NJdw/JKwkHxnAETctCFQ01GcKhEazXCv1l8LYoXkmFxRD ftX1/Z6lNxkT70S7kwuImsr0xpjUDcs5HuIyBEDxSRaDq4wzLA6+sbCA5e6UpziDcyropk fx7n4JcOruZvQmUQLel+8lYi/eG+/LU= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id e268004a (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:22:14 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 01/10] random: use sched_clock() for random_get_entropy() if no get_cycles() Date: Fri, 8 Apr 2022 20:21:36 +0200 Message-Id: <20220408182145.142506-2-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that a given arch does not define get_cycles(), falling back to the get_cycles() default implementation that returns 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. Cc: Thomas Gleixner Cc: Arnd Bergmann Cc: Theodore Ts'o Signed-off-by: Jason A. Donenfeld --- include/linux/timex.h | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/include/linux/timex.h b/include/linux/timex.h index 5745c90c8800..bd78f784762e 100644 --- a/include/linux/timex.h +++ b/include/linux/timex.h @@ -61,6 +61,7 @@ #include #include #include +#include #include @@ -74,8 +75,13 @@ * * By default we use get_cycles() for this purpose, but individual * architectures may override this in their asm/timex.h header file. + * If a given arch does not have get_cycles(), then we fallback to + * using sched_clock(). */ +#ifdef get_cycles #define random_get_entropy() ((unsigned long)get_cycles()) +#else +#define random_get_entropy() ((unsigned long)sched_clock()) #endif /* From patchwork Fri Apr 8 18:21:37 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807041 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 7CC00C43219 for ; Fri, 8 Apr 2022 18:22:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238567AbiDHSYh (ORCPT ); Fri, 8 Apr 2022 14:24:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238574AbiDHSYf (ORCPT ); Fri, 8 Apr 2022 14:24:35 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D47D375A83; Fri, 8 Apr 2022 11:22:30 -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 dfw.source.kernel.org (Postfix) with ESMTPS id DE6E86220D; Fri, 8 Apr 2022 18:22:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A2CBFC385A3; Fri, 8 Apr 2022 18:22:25 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="mm79Jlmn" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442144; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Azmq3qhRrdkmHljnnsXC3++LJCKNZe+lfezvnYnc39M=; b=mm79Jlmn+haFAeapmSSeR84SfB+kF20VVnX1H8gOS6Bf8q6dkzg7hgzuYdV6/IoFvyGhc+ ItuQlkzFGEsb+99E3m/AyLbHKsPXgOchjLh7R8DmhjfZMauNBrFmCRpgGwBkz8XmOxov5y BXW3244pE066ktXzUnEWutqdW49uT2A= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id c95c2b8f (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:22:23 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 02/10] m68k: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:37 +0200 Message-Id: <20220408182145.142506-3-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. Cc: Arnd Bergmann Cc: Geert Uytterhoeven Signed-off-by: Jason A. Donenfeld --- arch/m68k/include/asm/timex.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/m68k/include/asm/timex.h b/arch/m68k/include/asm/timex.h index 6a21d9358280..2cd0942097f8 100644 --- a/arch/m68k/include/asm/timex.h +++ b/arch/m68k/include/asm/timex.h @@ -7,6 +7,8 @@ #ifndef _ASMm68K_TIMEX_H #define _ASMm68K_TIMEX_H +#include + #ifdef CONFIG_COLDFIRE /* * CLOCK_TICK_RATE should give the underlying frequency of the tick timer @@ -35,7 +37,7 @@ static inline unsigned long random_get_entropy(void) { if (mach_random_get_entropy) return mach_random_get_entropy(); - return 0; + return sched_clock(); } #define random_get_entropy random_get_entropy From patchwork Fri Apr 8 18:21:38 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807042 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 BF053C433F5 for ; Fri, 8 Apr 2022 18:22:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238591AbiDHSYo (ORCPT ); Fri, 8 Apr 2022 14:24:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238570AbiDHSYm (ORCPT ); Fri, 8 Apr 2022 14:24:42 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C01337868E; Fri, 8 Apr 2022 11:22:38 -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 dfw.source.kernel.org (Postfix) with ESMTPS id DADB66220E; Fri, 8 Apr 2022 18:22:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97ECEC385A3; Fri, 8 Apr 2022 18:22:33 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="djbMPAQR" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442153; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jAgaDVvKz2mrahZxhZJxvyI0QeySOXC+VCOwMUwenjM=; b=djbMPAQR4aqJUQDv+3pg3YapaJCJtrqHTv182qnVHzhzX38f/Gy5cwbRLXMn1fX0kpVI9h EMnqZPYoR76vXVWG+QR8GFe8DR0F8gnqmvU01F8MCU5X46mkfIP/s+eXJyzk4PzQijiyvd zxhAQBPpNZOLAiRbTPg/OR/eSF3huiY= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 9ab255ec (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:22:32 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 03/10] riscv: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:38 +0200 Message-Id: <20220408182145.142506-4-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. Cc: Arnd Bergmann Cc: Paul Walmsley Cc: Palmer Dabbelt Signed-off-by: Jason A. Donenfeld --- arch/riscv/include/asm/timex.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h index 507cae273bc6..5b802755ca3a 100644 --- a/arch/riscv/include/asm/timex.h +++ b/arch/riscv/include/asm/timex.h @@ -7,6 +7,7 @@ #define _ASM_RISCV_TIMEX_H #include +#include typedef unsigned long cycles_t; @@ -41,7 +42,7 @@ static inline u32 get_cycles_hi(void) static inline unsigned long random_get_entropy(void) { if (unlikely(clint_time_val == NULL)) - return 0; + return sched_clock(); return get_cycles(); } #define random_get_entropy() random_get_entropy() From patchwork Fri Apr 8 18:21:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807043 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 1EE9EC433F5 for ; Fri, 8 Apr 2022 18:23:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238616AbiDHSZK (ORCPT ); Fri, 8 Apr 2022 14:25:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41830 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237803AbiDHSYx (ORCPT ); Fri, 8 Apr 2022 14:24:53 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC83937C91E; Fri, 8 Apr 2022 11:22:48 -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 A5DC4B82CDC; Fri, 8 Apr 2022 18:22:47 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AFAEC385A1; Fri, 8 Apr 2022 18:22:42 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="GAIaUJEC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442162; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DbIus65zpzI+xHKEAM5+xHyu+CtmATmWW3aZiXwzgc4=; b=GAIaUJEC1HUSfuNdrnqAWUTn3284cm/0xfh3fiKI5ZuipFFMuZvPn8LjBm4e+qk0cDLs3N 9VBsCM134dJPVZQe2Z1dOghNMM/0hI7v2FG5TdMR6v08EqeWuaCzCNYpKR7kcHopDDiZi5 UhU8/gd1mZNEseTUYlFrm8hfIl5ta+Q= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 94b0c155 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:22:41 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 04/10] mips: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:39 +0200 Message-Id: <20220408182145.142506-5-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. Cc: Arnd Bergmann Cc: Thomas Bogendoerfer Signed-off-by: Jason A. Donenfeld --- arch/mips/include/asm/timex.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/include/asm/timex.h b/arch/mips/include/asm/timex.h index b05bb70a2e46..1de8ded08bb7 100644 --- a/arch/mips/include/asm/timex.h +++ b/arch/mips/include/asm/timex.h @@ -12,6 +12,7 @@ #ifdef __KERNEL__ #include +#include #include #include @@ -94,7 +95,7 @@ static inline unsigned long random_get_entropy(void) else if (likely(imp != PRID_IMP_R6000 && imp != PRID_IMP_R6000A)) return read_c0_random(); else - return 0; /* no usable register */ + return sched_clock(); /* no usable register */ } #define random_get_entropy random_get_entropy From patchwork Fri Apr 8 18:21:40 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807054 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 10C0BC433FE for ; Fri, 8 Apr 2022 18:23:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238603AbiDHSZO (ORCPT ); Fri, 8 Apr 2022 14:25:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42498 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238611AbiDHSZI (ORCPT ); Fri, 8 Apr 2022 14:25:08 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 484FE37F902; Fri, 8 Apr 2022 11:22:56 -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 dfw.source.kernel.org (Postfix) with ESMTPS id D984162213; Fri, 8 Apr 2022 18:22:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A3572C385A1; Fri, 8 Apr 2022 18:22:51 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="G6BU8Ywm" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442170; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jfm/+0nZe/a0gZ1BVOi1xoOTd0LXu2XtqvwNu5ICWks=; b=G6BU8YwmryDS1gmWE+VsSKq/CaivlVVRO+4FBmjCGpVgAiTEzz4rBGY2zrzrcC6JvcSxxJ QBlo+NeO6cN98+dyhw52GgoZFCETJXKA3Zs612fg5YoJ6Q03UdzN8+K83P/PaMf7MKK1nJ Bi7Y4m7JizYUQvonoKB619aaE5aOiKI= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id c108eea7 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:22:50 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 05/10] arm: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:40 +0200 Message-Id: <20220408182145.142506-6-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. Cc: Arnd Bergmann Cc: Russell King Signed-off-by: Jason A. Donenfeld --- arch/arm/include/asm/timex.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/arm/include/asm/timex.h b/arch/arm/include/asm/timex.h index 7c3b3671d6c2..1c51580ee55d 100644 --- a/arch/arm/include/asm/timex.h +++ b/arch/arm/include/asm/timex.h @@ -9,7 +9,18 @@ #ifndef _ASMARM_TIMEX_H #define _ASMARM_TIMEX_H +#include + typedef unsigned long cycles_t; #define get_cycles() ({ cycles_t c; read_current_timer(&c) ? 0 : c; }) +static inline unsigned long random_get_entropy(void) +{ + unsigned long ret = get_cycles(); + if (ret) + return ret; + return sched_clock(); +} +#define random_get_entropy random_get_entropy + #endif From patchwork Fri Apr 8 18:21:41 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807055 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 A0751C43217 for ; Fri, 8 Apr 2022 18:23:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232556AbiDHSZR (ORCPT ); Fri, 8 Apr 2022 14:25:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42030 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238615AbiDHSZK (ORCPT ); Fri, 8 Apr 2022 14:25:10 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 49D8938237B; Fri, 8 Apr 2022 11:23:04 -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 dfw.source.kernel.org (Postfix) with ESMTPS id D981C621E6; Fri, 8 Apr 2022 18:23:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99E13C385A3; Fri, 8 Apr 2022 18:22:59 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="CLPULdzg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QhQ1HwDDQ0VBViTeG0LB+139Jo2Xk5438IuvpR3RiNg=; b=CLPULdzgGXJrwK4uCCHM7+j7CQPO/TnUdFHV8jGVPXt2oRPuFGfQuIGVwrwhQmuAXIEyIK +pMFaA2OsSQLAz2u75tmYrg486K8df6y/V/MHRdhzu90z8Dl9A4EKbCnoFVpvWCWqoNp4p IgJX3Y50X9yQA9wOGJqYKrd+/9+6GG8= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 2adbe4d1 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:22:58 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 06/10] x86: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:41 +0200 Message-Id: <20220408182145.142506-7-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. If CONFIG_X86_TSC=n, then it's possible that we're running on a 486 with no RDTSC, so we only need the fallback code for that case. Cc: Arnd Bergmann Cc: x86@kernel.org Signed-off-by: Jason A. Donenfeld --- arch/x86/include/asm/tsc.h | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/include/asm/tsc.h b/arch/x86/include/asm/tsc.h index 01a300a9700b..b0c0b2b9e0f7 100644 --- a/arch/x86/include/asm/tsc.h +++ b/arch/x86/include/asm/tsc.h @@ -5,6 +5,7 @@ #ifndef _ASM_X86_TSC_H #define _ASM_X86_TSC_H +#include #include #include @@ -28,6 +29,16 @@ static inline cycles_t get_cycles(void) return rdtsc(); } +static inline unsigned long random_get_entropy(void) +{ +#ifndef CONFIG_X86_TSC + if (!boot_cpu_has(X86_FEATURE_TSC)) + return sched_clock(); +#endif + return rdtsc(); +} +#define random_get_entropy random_get_entropy + extern struct system_counterval_t convert_art_to_tsc(u64 art); extern struct system_counterval_t convert_art_ns_to_tsc(u64 art_ns); From patchwork Fri Apr 8 18:21:42 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807056 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 57555C433EF for ; Fri, 8 Apr 2022 18:23:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238657AbiDHSZf (ORCPT ); Fri, 8 Apr 2022 14:25:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43260 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238614AbiDHSZS (ORCPT ); Fri, 8 Apr 2022 14:25:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5A99385F1B; Fri, 8 Apr 2022 11:23:13 -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 9962DB82CE1; Fri, 8 Apr 2022 18:23:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 96180C385A3; Fri, 8 Apr 2022 18:23:07 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="bHvsH7he" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442186; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=78dSRR6cg4Cb6xE6wzqZl0y3T/C5RqbL9OTQfhaSus0=; b=bHvsH7heTJ22wd9kOVkjQRjB8qxqDYb0Neo0BG7ETnElqZmWD+KvzZiWfTFZwr1zQmUbC5 XXdPLoX/hfqwadSYoHEgXfmb2MBW+rOO7AO7VyqUuq9QbfjjauYGlTUsreemS7BXRmsC9S aoLAL9JjFgYgrOUBP32exCl+fVMfezY= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 2a1ba7e8 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:23:06 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 07/10] arm64: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:42 +0200 Message-Id: <20220408182145.142506-8-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. If CONFIG_ARM_ARCH_TIMER=n, then get_cycles() will return 0, so we only need the fallback code for that case. Cc: Arnd Bergmann Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Jason A. Donenfeld --- arch/arm64/include/asm/timex.h | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/arm64/include/asm/timex.h b/arch/arm64/include/asm/timex.h index cf59ce91b22d..bfebd2e1ce45 100644 --- a/arch/arm64/include/asm/timex.h +++ b/arch/arm64/include/asm/timex.h @@ -13,6 +13,15 @@ */ #define get_cycles() arch_timer_read_counter() +#ifndef CONFIG_ARM_ARCH_TIMER +/* + * The default implementation of random_get_entropy() calls get_cycles(), + * which will return 0 if CONFIG_ARM_ARCH_TIMER=n, so we fall back to + * sched_clock() here. Not a great situation, but better than nothing. + */ +#define random_get_entropy() ((unsigned long)sched_clock()) +#endif + #include #endif From patchwork Fri Apr 8 18:21:43 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807057 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 ECEA3C4332F for ; Fri, 8 Apr 2022 18:23:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238665AbiDHSZg (ORCPT ); Fri, 8 Apr 2022 14:25:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238633AbiDHSZY (ORCPT ); Fri, 8 Apr 2022 14:25:24 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4032B388C74; Fri, 8 Apr 2022 11:23:19 -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 dfw.source.kernel.org (Postfix) with ESMTPS id D443062213; Fri, 8 Apr 2022 18:23:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FB3BC385A3; Fri, 8 Apr 2022 18:23:14 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="aQX3TeNo" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442193; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/gSxv4fNuqOrrrmMH7+ftUspm7t2MfvPel8L6C8Lv04=; b=aQX3TeNoQ+QPwL8ndARaAfDg11wsJ/YFju+XvbVGJVNyL0LmZc+hDJK7/o16t+IHMdwpvI xtvhii8Iw7wWFLushibaSZy3vV9y/yroybqjTxkHmVSfenFP7sC/ErHxl7tvuHgtuCA48c Qkej7EwLwnOiXDFxDvxO5DE8fShgI0g= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id e0f02080 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:23:13 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 08/10] um: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:43 +0200 Message-Id: <20220408182145.142506-9-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. This is accomplished by just including the asm-generic code like on other architectures, which means we can get rid of the empty stub function here. Cc: Arnd Bergmann Cc: Richard Weinberger Cc: Anton Ivanov Cc: Johannes Berg Signed-off-by: Jason A. Donenfeld --- arch/um/include/asm/timex.h | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/arch/um/include/asm/timex.h b/arch/um/include/asm/timex.h index e392a9a5bc9b..9f27176adb26 100644 --- a/arch/um/include/asm/timex.h +++ b/arch/um/include/asm/timex.h @@ -2,13 +2,8 @@ #ifndef __UM_TIMEX_H #define __UM_TIMEX_H -typedef unsigned long cycles_t; - -static inline cycles_t get_cycles (void) -{ - return 0; -} - #define CLOCK_TICK_RATE (HZ) +#include + #endif From patchwork Fri Apr 8 18:21:44 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807058 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 76E31C433EF for ; Fri, 8 Apr 2022 18:24:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238713AbiDHS0G (ORCPT ); Fri, 8 Apr 2022 14:26:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238668AbiDHSZg (ORCPT ); Fri, 8 Apr 2022 14:25:36 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E2E9390CD2; Fri, 8 Apr 2022 11:23:29 -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 dfw.source.kernel.org (Postfix) with ESMTPS id CBF71621EF; Fri, 8 Apr 2022 18:23:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93E11C385A5; Fri, 8 Apr 2022 18:23:24 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="jQIWOLhO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442202; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yN+amZ/gYA3bch1ZPQw4W7sQ+gf5w/y9JgysyWp/RDk=; b=jQIWOLhOUxBvoZusFmG6avdoNOZumfkFzlX9JI+3sz/6LcZi6fiHz50PhiH1f/pdI/MtFy m9sMAaUA8mqTbw1Qy+VONizn1MdUAgqLlxFGn0j+LDdVGvybZYqkC9KIQHfkrtMbsi6/b8 O6Q/CydOHJ0sqZXSrnNhN0PBk1v565E= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 28c99cda (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:23:22 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 09/10] sparc: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:44 +0200 Message-Id: <20220408182145.142506-10-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. This is accomplished by just including the asm-generic code like on other architectures, which means we can get rid of the empty stub function here. Cc: Arnd Bergmann Cc: David S. Miller Signed-off-by: Jason A. Donenfeld --- arch/sparc/include/asm/timex_32.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/sparc/include/asm/timex_32.h b/arch/sparc/include/asm/timex_32.h index 542915b46209..f86326a6f89e 100644 --- a/arch/sparc/include/asm/timex_32.h +++ b/arch/sparc/include/asm/timex_32.h @@ -9,8 +9,6 @@ #define CLOCK_TICK_RATE 1193180 /* Underlying HZ */ -/* XXX Maybe do something better at some point... -DaveM */ -typedef unsigned long cycles_t; -#define get_cycles() (0) +#include #endif From patchwork Fri Apr 8 18:21:45 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Jason A. Donenfeld" X-Patchwork-Id: 12807059 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 98605C433EF for ; Fri, 8 Apr 2022 18:24:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238646AbiDHS0J (ORCPT ); Fri, 8 Apr 2022 14:26:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44666 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238683AbiDHSZq (ORCPT ); Fri, 8 Apr 2022 14:25:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4795B396E17; Fri, 8 Apr 2022 11:23: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 dfw.source.kernel.org (Postfix) with ESMTPS id BCD7262213; Fri, 8 Apr 2022 18:23:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8946FC385A5; Fri, 8 Apr 2022 18:23:32 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="X5Gkobvj" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1649442212; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X+SOXCxlTVp5T6r4OXCDhv2RSY3Z97e2yzOuZYoobyg=; b=X5Gkobvj4quH9iXj/OmVaky1rOe+XlIiOQkQwsW/YXlqbHU2kvCpAxr3F4BlAiUBJjacz4 4hLrdMULeI/cM/0ZYjOyJ5ULjjQszeCJT4hYpzk92ZapKgN5ISsrXbdV5iB2kpZxcK0qe6 yMVMQkcZxubXBYCwgD1TiGQ4JjUNu+I= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id a12bc66c (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Fri, 8 Apr 2022 18:23:31 +0000 (UTC) From: "Jason A. Donenfeld" To: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, arnd@arndb.de Cc: "Jason A. Donenfeld" , Theodore Ts'o , Dominik Brodowski , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Thomas Bogendoerfer , Paul Walmsley , Palmer Dabbelt , Albert Ou , "David S . Miller" , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , linux-arm-kernel@lists.infradead.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-riscv@lists.infradead.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, x86@kernel.org, linux-xtensa@linux-xtensa.org Subject: [PATCH RFC v1 10/10] xtensa: use sched_clock() for random_get_entropy() instead of zero Date: Fri, 8 Apr 2022 20:21:45 +0200 Message-Id: <20220408182145.142506-11-Jason@zx2c4.com> In-Reply-To: <20220408182145.142506-1-Jason@zx2c4.com> References: <20220408182145.142506-1-Jason@zx2c4.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-mips@vger.kernel.org In the event that random_get_entropy() can't access a cycle counter or similar, falling back to returning 0 is really not the best we can do. Instead, at least calling sched_clock() would be preferable, because that always needs to return _something_, even falling back to jiffies eventually. It's not as though sched_clock() is super high precision or guaranteed to be entropic, but basically anything that's not zero all the time is better than returning zero all the time. This is accomplished by just including the asm-generic code like on other architectures, which means we can get rid of the empty stub function here. Cc: Arnd Bergmann Cc: Max Filippov Signed-off-by: Jason A. Donenfeld --- arch/xtensa/include/asm/timex.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/xtensa/include/asm/timex.h b/arch/xtensa/include/asm/timex.h index 233ec75e60c6..3f2462f2d027 100644 --- a/arch/xtensa/include/asm/timex.h +++ b/arch/xtensa/include/asm/timex.h @@ -29,10 +29,6 @@ extern unsigned long ccount_freq; -typedef unsigned long long cycles_t; - -#define get_cycles() (0) - void local_timer_setup(unsigned cpu); /* @@ -59,4 +55,6 @@ static inline void set_linux_timer (unsigned long ccompare) xtensa_set_sr(ccompare, SREG_CCOMPARE + LINUX_TIMER); } +#include + #endif /* _XTENSA_TIMEX_H */