linux-kernel - Re: x86/random: Speculation to the rescue

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-=wg7YAx_+CDe6fUqApPD_ghP18H9sPnJWWUg32pQ4pU82g@mail.gmail.com>
Date:   Mon, 30 Sep 2019 09:15:55 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        "Ahmed S. Darwish" <darwish.07@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Nicholas Mc Guire <hofrat@...ntech.at>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: x86/random: Speculation to the rescue

On Mon, Sep 30, 2019 at 6:16 AM Theodore Y. Ts'o <tytso@....edu> wrote:
>
> Which is to say, I'm still worried that people with deep access to the
> implementation details of a CPU might be able to reverse engineer what
> a jitter entropy scheme produces.  This is why I'd be curious to see
> the results when someone tries to attack a jitter scheme on a fully
> open, simple architecture such as RISC-V.

Oh, I agree.

One of the reasons I didn't like some of the other jitter entropy
things was that they seemed to rely _entirely_ on just purely
low-level CPU unpredictability. I think that exists, but I think it
makes for problems for really simple cores.

Timing over a bigger thing and an actual interrupt (even if it's
"just" a timer interrupt, which is arguably much closer to the CPU and
has a much higher likelihood of having common frequency domains with
the cycle counter etc) means that I'm pretty damn convinced that a big
complex CPU will absolutely see issues, even if it has big caches.

But it _also_ means that if you have a small and excessively stupid
in-order CPU, I can almost guarantee that you will at least have cache
misses likely all the way out to memory. So a CPU-only loop like the
LFSR thing that Thomas reports generates entropy even on its own would
likely generate nothing at all on a simple in-order core - but I do
think that with timers and real cache misses etc, it's going to be
really really hard to try to figure out cycle counters even if you're
a CPU expert.

But the embedded market with small cores and 100% identical machines
and 100% identical system images is always going to be a potential
huge problem.

If somebody has connections to RISC-V hw people, maybe they could
bring this issue up with them?

                  Linus