linux-kernel - Re: [PATCH] crypto: jitterentropy

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 5 Oct 2020 07:19:18 +0100
From:   Christoph Hellwig <hch@...radead.org>
To:     Ard Biesheuvel <ardb@...nel.org>
Cc:     Stephan M??ller <smueller@...onox.de>,
        Palmer Dabbelt <palmerdabbelt@...gle.com>,
        Christoph Hellwig <hch@...radead.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        kernel test robot <lkp@...el.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] crypto: jitterentropy - bind statically into kernel

On Sun, Oct 04, 2020 at 11:16:10PM +0200, Ard Biesheuvel wrote:
> On Sun, 4 Oct 2020 at 20:48, Stephan M??ller <smueller@...onox.de> wrote:
> >
> > The RISC-V architecture is about to implement the callback
> > random_get_entropy with a function that is not exported to modules.
> 
> Why is that? Wouldn't it be better to export the symbol instead?

get_cycles is a low-level time keeping detail that really should not
be exported, and at least for RISC-V this would be the only modular
user.  Once that is sorted out I'll audit other common architectures
to drop the export, as it isn't something that should be used in ramdom
driver code.