[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190930131639.GF4994@mit.edu>
Date: Mon, 30 Sep 2019 09:16:39 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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 Sun, Sep 29, 2019 at 11:37:06PM -0400, Theodore Y. Ts'o wrote:
> I'm OK with this as a starting point. If a jitter entropy system
> allow us to get pass this logjam, let's do it. At least for the x86
> architecture, it will be security through obscurity. And if the
> alternative is potentially failing where the adversary can attack the
> CRNG, it's my preference. It's certainly better than nothing.
Upon rereading this, this came out wrong. What I was trying to say is
in the very worst case, it will be security through obscurity, and if
the alternative "don't block, because blocking is always worse than an
guessable value being returned through getrandom(0)", it's better than
nothing.
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.
- Ted
Powered by blists - more mailing lists