linux-kernel - Re: [PATCH RFC v0] random: block in /dev/urandom

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: <b43cc58-5ace-11e1-1a11-6cca42f65e7@linux-m68k.org>
Date:   Tue, 15 Feb 2022 09:53:11 +1100 (AEDT)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
cc:     Joshua Kinard <kumba@...too.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        "open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Eric Biggers <ebiggers@...gle.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Lennart Poettering <mzxreary@...inter.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>
Subject: Re: [PATCH RFC v0] random: block in /dev/urandom

On Mon, 14 Feb 2022, Jason A. Donenfeld wrote:

> 
> So the only systems we're actually talking about without a good cycle 
> counter are non-Amiga m68k? If so, that'd be a pretty terrific finding. 
> It'd mean that this idea can move forward, and we only need to worry 
> about some m68k museum pieces with misconfigured userspaces...
> 

A processor cycle counter is helpful when mounting a timing attack but my 
museum pieces don't suffer from that problem.

Also, they are and always were immune from spectre, meltdown etc.

You misrepresent those secure hardware designs as being problematic, just 
because of some bad advice on some random blogs about RNG API usage.

Do you have a phone that no longer gets updates from its vendor? Have you 
tried patching it?

Your insecure museum pieces are the real problem, not my secure ones.