linux-kernel - Re: [GIT pull] x86/urgent for 5.3-rc5

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: <CAHk-=wiV54LwvWcLeATZ4q7rA5Dd9kE0Lchx=k023kgxFHySNQ@mail.gmail.com>
Date:   Sun, 25 Aug 2019 10:37:47 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Borislav Petkov <bp@...e.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [GIT pull] x86/urgent for 5.3-rc5

On Sun, Aug 25, 2019 at 10:30 AM Borislav Petkov <bp@...e.de> wrote:
>
> Should we do that somewhere in the early boot code by adding a WARN_ON()
> or so and see who screams?

It might be a good idea, just to see if it ever happens (again).

It doesn't even have to be early boot. It's probably more important to
let the user _know_, than it is to then disable the rdrand
instruction.

Particularly since we might as well just do it in general, and in the
general case we don't even know how to hide it in cpuid. So maybe just
something like "read the rdrand value a few times, make sure it
actually changes" at CPU bring-up (both boot and resume)

It sounds like a stupid test, but considering that AMD has had this
particular bug now several times over at least three different
generations, maybe it's not a stupid test after all.

Who knows what the Chinese CPU's that use the AMD core do? Hygon?
Whatever. Did they get the firmware fixes?

              Linus