Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp635996lfv; Tue, 12 Apr 2022 00:34:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz61lHBKikCz3Mv5SDHCW8zWHfo0+obK8njL62Y5L3LYn8vyoFLiwXsl8OK23Ju1cFFf99K X-Received: by 2002:a05:6402:3717:b0:41d:3ce:1a36 with SMTP id ek23-20020a056402371700b0041d03ce1a36mr27097676edb.180.1649748864071; Tue, 12 Apr 2022 00:34:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649748864; cv=none; d=google.com; s=arc-20160816; b=K9Hnilqx0IH9Vigb/4ePzFY7PyclwD18oVqj5g/RASeu+IYBSP6/vytgCzlPYN+BP5 w9Y1bop7fL/vCV4Y61Jun2ii9oBd7otSp6btEHaP6jO10+581xUzyBlAQ6/b060tWbtZ 8QxbBcAiZC7qnC+6ActBl6Se3LQBFjFlkyl52jzsG6WijChzGM9lH1HG+VPy8Vf+UDBj llJMXstavpAu4HceBbDrRB+osi9aQ4lC34eG7Bh61qclWtaqoCqHHEfsbQtClR4wrWIq 8SSfSQJLZpppljMDE3PxH3wwx5HIdgomtzoCGrZqUD03wttHfG2rzZ5Rn7Cug00TvsGf QFUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=xjhhzRNcm78JGgGtLG6mgwaGj8Cww0Tlt26NaB6GyE8=; b=YEqftNLsa1X8bmG3A2NdzUuniOss9LenjRZ2LEvIvJP+JZ+fBiRIQel0xF/J2ihlmy NF6N6LvBMrbEIdXdIAj/cSMBafZzmiPnG4+Ra6XYBxx5S13H6FMCCxxrQqAtJC+ofzcx AGFsGomdRgrzfQiJhdUOZadzoKEkPaiH22j1VP39P4cls1k+v42KZZx79iOFtVHmPFDT DC26cwrXKgaAE949w8Qn8Ab+YiQmECWlwauC0ke63vmCE0XRH841OL9Dp6tWeTASrIBL 9iVooA008yXc2EmLWElu9PfGC3JdKTtKBLvrt7GlmZ0dnBGD5uUIq5wGB+/zeQo8Kdv2 6qiA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=bQRUSKc6; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id dt5-20020a170906b78500b006e78f6856c7si8299762ejb.613.2022.04.12.00.33.50; Tue, 12 Apr 2022 00:34:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-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=@linutronix.de header.s=2020 header.b=bQRUSKc6; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343676AbiDKIUr (ORCPT + 99 others); Mon, 11 Apr 2022 04:20:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1343669AbiDKIUq (ORCPT ); Mon, 11 Apr 2022 04:20:46 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D931A33A10; Mon, 11 Apr 2022 01:18:32 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1649665111; 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=xjhhzRNcm78JGgGtLG6mgwaGj8Cww0Tlt26NaB6GyE8=; b=bQRUSKc6DEfWq2JW4zBYVX9dk6BAlFAOz8ziZI1nuAr8ThUSn9e4Pp4TH0bz7ykDdAbytZ 7E1JFmxLLPSA9yL/pLdV+Narb8ojwoUuHfRpcDWF7RSs/XNw8NP/mtP12PhEDKsDgxWdwX vj1X7Tk9jubTJlEIAMDexIL70/zM+Ev13+w45xEIm/Pg10UwmbczcL33LQfaYjkFbjCAwR nWRv8uLzxf0uwY7wWrnhC9hKJv5hsVxGhFPLc//BILYIvle9sl9xbz+4/B2WaiAREmOlO7 QMeWCwYxU6fvIGepcveLrvpqjGJJ/UVr5H5Gu5FcUTDSJ2ZLo6XAuABFlQLZ3A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1649665111; 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=xjhhzRNcm78JGgGtLG6mgwaGj8Cww0Tlt26NaB6GyE8=; b=dYt2Xa6X2UETGYKSaI3sFGG38t3wto/bY9ksZnmh+Jh5QgkWcPQfA5MzFrnWyF0a21HHlJ MeANaRegf0On2MDw== To: "Jason A. Donenfeld" , 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 , Ingo Molnar , Borislav Petkov , Dave Hansen , "H . Peter Anvin" , Chris Zankel , Max Filippov , John Stultz , Stephen Boyd , Dinh Nguyen , 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: Re: [PATCH v2 03/11] m68k: use ktime_read_raw_clock() for random_get_entropy() instead of zero In-Reply-To: <20220410214951.55294-4-Jason@zx2c4.com> References: <20220410214951.55294-1-Jason@zx2c4.com> <20220410214951.55294-4-Jason@zx2c4.com> Date: Mon, 11 Apr 2022 10:18:30 +0200 Message-ID: <87sfqkf2y1.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE 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-crypto@vger.kernel.org On Sun, Apr 10 2022 at 23:49, Jason A. Donenfeld wrote: > 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 ktime_read_raw_clock() would be preferable, > because that always needs to return _something_, even falling back to > jiffies eventually. It's not as though ktime_read_raw_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: Geert Uytterhoeven > Signed-off-by: Jason A. Donenfeld > --- > arch/m68k/include/asm/timex.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/m68k/include/asm/timex.h b/arch/m68k/include/asm/timex.h > index 6a21d9358280..5351b10e1b18 100644 > --- a/arch/m68k/include/asm/timex.h > +++ b/arch/m68k/include/asm/timex.h > @@ -35,7 +35,7 @@ static inline unsigned long random_get_entropy(void) > { > if (mach_random_get_entropy) > return mach_random_get_entropy(); > - return 0; > + return ktime_read_raw_clock(); I'd rather do something like this in a common header: unsigned long random_get_entropy_fallback(void); and use random_get_entropy_fallback() in the architecture specific files. That way you can encapsulate the fallback implementation in the random code and if it turns out that ktime_read_raw_clock() is a stupid idea or someone has a better idea then you have to change exactly one place and not patch the whole tree again. Thanks, tglx