[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <161124379345.536991.7126735996539393054.b4-ty@kernel.org>
Date: Thu, 21 Jan 2021 17:53:18 +0000
From: Will Deacon <will@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>, tytso@....edu
Cc: catalin.marinas@....com, kernel-team@...roid.com,
Will Deacon <will@...nel.org>, mark.rutland@....com,
broonie@...nel.org, linux-arm-kernel@...ts.infradead.org,
maz@...nel.org, linux-kernel@...r.kernel.org,
andre.przywara@....com
Subject: Re: [PATCH] random: avoid arch_get_random_seed_long() when collecting IRQ randomness
On Thu, 5 Nov 2020 16:29:44 +0100, Ard Biesheuvel wrote:
> When reseeding the CRNG periodically, arch_get_random_seed_long() is
> called to obtain entropy from an architecture specific source if one
> is implemented. In most cases, these are special instructions, but in
> some cases, such as on ARM, we may want to back this using firmware
> calls, which are considerably more expensive.
>
> Another call to arch_get_random_seed_long() exists in the CRNG driver,
> in add_interrupt_randomness(), which collects entropy by capturing
> inter-interrupt timing and relying on interrupt jitter to provide
> random bits. This is done by keeping a per-CPU state, and mixing in
> the IRQ number, the cycle counter and the return address every time an
> interrupt is taken, and mixing this per-CPU state into the entropy pool
> every 64 invocations, or at least once per second. The entropy that is
> gathered this way is credited as 1 bit of entropy. Every time this
> happens, arch_get_random_seed_long() is invoked, and the result is
> mixed in as well, and also credited with 1 bit of entropy.
>
> [...]
Applied to arm64 (for-next/random), thanks!
[1/1] random: avoid arch_get_random_seed_long() when collecting IRQ randomness
https://git.kernel.org/arm64/c/390596c9959c
Ted -- please shout if you would prefer me not to carry this in the arm64
tree. I've haven't seen a response from you on this thread, but this patch
is currently blocking support for the TRNG firmware call on arm64 [1], so
I've pulled it in as a dependency. The branch above is stable, so you can
pull it in as well if necessary.
[1] https://lore.kernel.org/r/20210106103453.152275-1-andre.przywara@arm.com
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
Powered by blists - more mailing lists