linux-kernel - Re: [PATCH] random: remove CONFIG_ARCH

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: <11C903CC-22A7-48EE-AD63-E71CC8D28B88@zytor.com>
Date:   Tue, 05 Jul 2022 14:50:34 -0700
From:   "H. Peter Anvin" <hpa@...or.com>
To:     Borislav Petkov <bp@...en8.de>,
        "Jason A. Donenfeld" <Jason@...c4.com>
CC:     linux-arm-kernel@...ts.infradead.org,
        linuxppc-dev@...ts.ozlabs.org, linux-s390@...r.kernel.org,
        linux-kernel@...r.kernel.org, x86@...nel.org,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Michael Ellerman <mpe@...erman.id.au>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"

On July 5, 2022 12:57:04 PM PDT, Borislav Petkov <bp@...en8.de> wrote:
>On Tue, Jul 05, 2022 at 09:44:17PM +0200, Jason A. Donenfeld wrote:
>> Oh, huh. Maybe in that case I should adjust the message to say "consider
>> using `random.trust_cpu=0`," which is the thing that would actually make
>> a security difference.
>
>Why isn't that option documented in
>Documentation/admin-guide/kernel-parameters.txt?
>
>> But actually, one thing that wasn't clear to me was: does `nordrand`
>> affect what userspace sees? While random.c is okay in lots of
>> circumstances, I could imagine `nordrand` playing a role in preventing
>> userspace from using it, which might be desirable. Is this the case? If
>> so, I can remove the nordrand chunk from this patch for v2. If not, I'll
>> adjust the text to mention `random.trust_cpu=0`.
>
>Unfortunately, it doesn't disable the instruction. It would be lovely if
>we had a switch like that...
>
>That's why this message is supposed to be noisy so that people can pay
>attention at least.
>
>> In the sense that random.c can handle mostly any input without making
>> the quality worse. So, you can't accidentally taint it. The only risk is
>> if it thinks RDRAND is good and trustable when it isn't, but that's what
>> `random.trust_cpu=0` is for.
>
>And that's why I'm saying that if you detect RDRAND returning the
>same thing over and over again, you should simply stop using it.
>Automatically. Not rely on the user to do anything.
>

It's just math. The only variable is your confidence level, i.e. at what level do you decide that the likelihood of pure chance is way smaller than the likelihood of hardware failure. For example, the likelihood of m n-bit samples in a row being identical is 2^-(n*(m-3/2)), and the likelihood of the CPU being destroyed by a meterorite in the same microsecond is about 2^-100.