On Sat, 23 Apr 2022 14:26:14 PDT (-0700), Jason@xxxxxxxxx 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 random_get_entropy_fallback() would be
preferable, because that always needs to return _something_, even
falling back to jiffies eventually. It's not as though
random_get_entropy_fallback() 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.
Makes sense: we had an architecturally-mandated timer at the time, but
we don't any more. Every real implementation has a timer right now, but
that may change in the future so it doesn't hurt to fix it before it's
broken.
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Arnd Bergmann <arnd@xxxxxxxx>
Cc: Paul Walmsley <paul.walmsley@xxxxxxxxxx>
Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx>
Signed-off-by: Jason A. Donenfeld <Jason@xxxxxxxxx>
---
arch/riscv/include/asm/timex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h
index 507cae273bc6..d6a7428f6248 100644
--- a/arch/riscv/include/asm/timex.h
+++ b/arch/riscv/include/asm/timex.h
@@ -41,7 +41,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 random_get_entropy_fallback();
return get_cycles();
}
#define random_get_entropy() random_get_entropy()
Fine for me if this goes in via some other tree, but also happy to take
it via the RISC-V tree if you'd like. IMO we could just call this a
fix, maybe
Fixes: aa9887608e77 ("RISC-V: Check clint_time_val before use")
(but that just brought this back, so there's likely older kernels broken
too). Shouldn't be breaking any real hardware, though, so no rush on my
end.
Acked-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
Reviewed-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
Thanks!
