linux-kernel - Re: [PATCH v6 08/17] riscv: use fallback for random_get

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9qosSq+3RYtBCMiS6yCaiZcJtaBW=8StMTACEkr3hVSow@mail.gmail.com>
Date:   Mon, 25 Apr 2022 17:02:49 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     Palmer Dabbelt <palmer@...belt.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Arnd Bergmann <arnd@...db.de>,
        Paul Walmsley <paul.walmsley@...ive.com>
Subject: Re: [PATCH v6 08/17] riscv: use fallback for random_get_entropy()
 instead of zero

Hi Palmer,

On Mon, Apr 25, 2022 at 4:55 PM Palmer Dabbelt <palmer@...belt.com> wrote:
> 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.

I'm going to take this series through the random.git tree, as I've got
things that build on top of it for random.c slated for 5.19.

> 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.

That'd be fine with me, but it'd involve also backporting the
timekeeping patch, which adds a new API, so maybe we better err on the
side of caution with that new code.

> Acked-by: Palmer Dabbelt <palmer@...osinc.com>
> Reviewed-by: Palmer Dabbelt <palmer@...osinc.com>

Thanks for the review.

> Makes sense: we had an architecturally-mandated timer at the time, but
> we don't any more.

That's too bad. Out of curiosity, what happened? Was that deemed too
expensive for certain types of chips that western digital wanted to
produce for their hard drives, or some really constrained use case
like that?

Jason