From: Linus Torvalds <email@example.com> To: "Theodore Y. Ts'o" <firstname.lastname@example.org> Cc: Thomas Gleixner <email@example.com>, "Ahmed S. Darwish" <firstname.lastname@example.org>, LKML <email@example.com>, Nicholas Mc Guire <firstname.lastname@example.org>, "the arch/x86 maintainers" <email@example.com>, Andy Lutomirski <firstname.lastname@example.org>, Kees Cook <email@example.com> Subject: Re: x86/random: Speculation to the rescue Date: Mon, 30 Sep 2019 09:15:55 -0700 [thread overview] Message-ID: <CAHk-=wg7YAx_+CDe6fUqApPD_ghP18H9sPnJWWUg32pQ4pU82g@mail.gmail.com> (raw) In-Reply-To: <20190930131639.GF4994@mit.edu> On Mon, Sep 30, 2019 at 6:16 AM Theodore Y. Ts'o <firstname.lastname@example.org> 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
next prev parent reply other threads:[~2019-09-30 16:16 UTC|newest] Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-28 22:24 Thomas Gleixner 2019-09-28 23:53 ` Linus Torvalds 2019-09-29 7:40 ` Thomas Gleixner 2019-09-29 8:05 ` Alexander E. Patrakov 2019-09-30 1:16 ` Linus Torvalds 2019-09-30 2:59 ` Linus Torvalds 2019-09-30 6:10 ` Borislav Petkov 2019-09-30 16:06 ` Linus Torvalds 2019-10-01 13:51 ` Borislav Petkov 2019-10-01 17:14 ` Linus Torvalds 2019-10-01 17:50 ` [PATCH] char/random: Add a newline at the end of the file Borislav Petkov 2019-09-30 18:05 ` x86/random: Speculation to the rescue Kees Cook 2019-09-30 3:37 ` Theodore Y. Ts'o 2019-09-30 13:16 ` Theodore Y. Ts'o 2019-09-30 16:15 ` Linus Torvalds [this message] 2019-09-30 16:32 ` Peter Zijlstra 2019-09-30 17:03 ` Linus Torvalds 2019-10-01 10:28 ` David Laight 2019-10-15 21:50 ` Thomas Gleixner 2019-10-01 16:15 ` Ahmed S. Darwish 2019-10-01 16:37 ` Kees Cook 2019-10-01 17:18 ` Ahmed S. Darwish 2019-10-01 17:25 ` Linus Torvalds 2019-10-06 12:07 ` Pavel Machek 2019-10-02 12:01 ` Theodore Y. Ts'o 2019-10-06 11:41 ` Pavel Machek 2019-10-06 17:26 ` Linus Torvalds 2019-10-06 17:35 ` Pavel Machek 2019-10-06 18:06 ` Linus Torvalds 2019-10-06 18:21 ` Pavel Machek 2019-10-06 18:26 ` Linus Torvalds 2019-10-07 11:47 ` Theodore Y. Ts'o 2019-10-07 22:18 ` Pavel Machek 2019-10-08 11:33 ` David Laight 2019-10-09 8:02 ` Pavel Machek 2019-10-09 9:37 ` David Laight 2019-10-01 2:14 hgntkwis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHk-=wg7YAx_+CDe6fUqApPD_ghP18H9sPnJWWUg32pQ4pU82g@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: x86/random: Speculation to the rescue' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).