From: Pavel Machek <pavel@ucw.cz>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
"Ahmed S. Darwish" <darwish.07@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Nicholas Mc Guire <hofrat@opentech.at>,
the arch/x86 maintainers <x86@kernel.org>,
Andy Lutomirski <luto@kernel.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: x86/random: Speculation to the rescue
Date: Tue, 8 Oct 2019 00:18:17 +0200 [thread overview]
Message-ID: <20191007221817.GA4027@amd> (raw)
In-Reply-To: <20191007114734.GA6104@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]
On Mon 2019-10-07 07:47:34, Theodore Y. Ts'o wrote:
> On Sun, Oct 06, 2019 at 08:21:03PM +0200, Pavel Machek wrote:
> > Even without cycle counter... if we _know_ we are trying to generate
> > entropy and have MMC available, we don't care about power and
> > performance.
> >
> > So we can just...
> >
> > issue read request on MMC
> > while (!interrupt_done)
> > i++
> >
> > ...and then use i++ as poor man's version of cycle counter.
>
> I suggest that you try that and see how much uncertainty you really
> have before you assume that this is actually going to work. Again, on
> "System on a Chip" systems, there is very likely a single master
> oscillator, and the eMMC is going to be on the the same silicon die as
> the CPU. At least for spinning rust platters it's on a physically
I have many systems including SoC here, but technology needed for NAND
flash is different from technology for CPU, so these parts do _not_
share a silicon die. They do not even share same package. (Also RTC
tends to be on separate chip, connected using i2c).
Would you have an example of Linux-capable system where eMMC is on
same chip as CPU?
> P.S. Note that this Don Davis's paper[1] claims that they were able
> to extract 100 independent unpredictable bits per _minute_. Given
> that modern init scripts want us to be able to boot in under a few
Well, for now I'm arguing that it is possible to gather entropy, not
neccessarily that it is going to be fast. Still waiting minute and a
half during boot is better than generating non-random keys.
Linux already credits interrupts with some entropy, so all I really
need to do is generate some interrupts. And "find /" generates lots of
those on embedded systems. (Even with nfsroot as long as network card
is not being polled...)
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2019-10-07 22:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-28 22:24 x86/random: Speculation to the rescue 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
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 [this message]
2019-10-08 11:33 ` David Laight
2019-10-09 8:02 ` Pavel Machek
2019-10-09 9:37 ` David Laight
-- strict thread matches above, loose matches on Subject: below --
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=20191007221817.GA4027@amd \
--to=pavel@ucw.cz \
--cc=darwish.07@gmail.com \
--cc=hofrat@opentech.at \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=x86@kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.