linux-kernel - [REGESSION] Bug 216502 - slow crng initialization on Rockchip 3399 (Friendyarm NanoPi M4)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4deaa04b-f103-9cc4-7946-9ea69afd94d0@leemhuis.info>
Date:   Sun, 18 Sep 2022 14:17:49 +0200
From:   Thorsten Leemhuis <regressions@...mhuis.info>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Mikhail Rudenko <mike.rudenko@...il.com>,
        Theodore Ts'o <tytso@....edu>,
        Eric Biggers <ebiggers@...gle.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        linux-crypto@...r.kernel.org
Subject: [REGESSION] Bug 216502 - slow crng initialization on Rockchip 3399
 (Friendyarm NanoPi M4)

Hi, this is your Linux kernel regression tracker speaking.

I noticed a regression report in bugzilla.kernel.org. As many (most?)
kernel developer don't keep an eye on it, I decided to forward it my
mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216502 :

> Crng initialization time has significantly increased on Rockchip
> 3399-based Friendyarm NanoPi M4 in v6.0.0-rc5 compared to v5.18.0 (from
> 2.36s since rootfs mounted to 8.55s since rootfs mounted). Bisection
> points at 78c768e619fb ("random: vary jitter iterations based on cycle
> counter speed"). Manually reverting that commit on top of v6.0.0-rc5
> fixes the issue. Attached dmesg logs correspond to vanilla v6.0.0-rc5
> ("bad") and v6.0.0-rc5 with 78c768e619fb reverted ("good").
See the ticket for more details. Apologies if I forwarded it to the
wrong folks, I cover a lot of ground and thus sometimes get things
wrong. :-/

BTW, I'd also like to add the report to the list of tracked regressions
to ensure it's doesn't fall through the cracks in the end:

#regzbot introduced: 78c768e619fb
https://bugzilla.kernel.org/show_bug.cgi?id=216502
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.