From: "Theodore Y. Ts'o" <firstname.lastname@example.org> To: Linus Torvalds <email@example.com> Cc: Thomas Gleixner <firstname.lastname@example.org>, "Ahmed S. Darwish" <email@example.com>, LKML <firstname.lastname@example.org>, Nicholas Mc Guire <email@example.com>, the arch/x86 maintainers <firstname.lastname@example.org>, Andy Lutomirski <email@example.com>, Kees Cook <firstname.lastname@example.org> Subject: Re: x86/random: Speculation to the rescue Date: Sun, 29 Sep 2019 23:37:06 -0400 [thread overview] Message-ID: <20190930033706.GD4994@mit.edu> (raw) In-Reply-To: <CAHk-=wi0vxLmwEBn2Xgu7hZ0U8z2kN4sgCax+57ZJMVo3huDaQ@mail.gmail.com> On Sun, Sep 29, 2019 at 06:16:33PM -0700, Linus Torvalds wrote: > > - or just say "hey, a lot of people find jitter entropy reasonable, > so let's just try this". > 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. That being said, I'd very much like to see someone do an analysis of how well these jitter schemes work on an RISC-V iplementation (you know, the ones that were so simplistic and didn't have any speculation so they weren't vulnerable to Specture/Meltdown). If jitter approaches turn out not to work that well on RISC-V, perhaps that will be a goad for future RISC-V chips to include the crypto extension to their ISA. In the long term (not in time for the 5.4 merge window), I'm convinced that we should be trying as many ways of getting entropy as possible. If we're using UEFI, we should be trying to get it from UEFI's secure random number generator; if there is a TPM, we should be trying to get random numbers from the RPM, and mix them in, and so on. After all, the reason why lived with getrandom(0) blocking for five years was because for the vast majority of x86 platforms, it simply wasn't problem in practice. We need to get back to that place where in practice, we've harvested as much uncertainty from hardware as possible, so most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security. - Ted
next prev parent reply other threads:[~2019-09-30 3:37 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 [this message] 2019-09-30 13:16 ` Theodore Y. Ts'o 2019-09-30 16:15 ` Linus Torvalds 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=20190930033706.GD4994@mit.edu \ --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).