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: <YsSXkNBtB6Ciy9iN@zn.tnic>
Date:   Tue, 5 Jul 2022 21:57:04 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     "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>,
        "H . Peter Anvin" <hpa@...or.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH] random: remove CONFIG_ARCH_RANDOM and "nordrand"

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.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ