[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191006182103.GA2394@amd>
Date: Sun, 6 Oct 2019 20:21:03 +0200
From: Pavel Machek <pavel@....cz>
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>,
Theodore Ts'o <tytso@....edu>,
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 2019-10-06 11:06:38, Linus Torvalds wrote:
> On Sun, Oct 6, 2019 at 10:35 AM Pavel Machek <pavel@....cz> wrote:
> >
> > It will not: boot is now halted because systemd wants some
> > entropy. Everything is idle and very little interrupts are
> > happening. We have spinning rust, but it is idle, and thus not
> > generating any interrupts.
>
> Yes, but we have that problem now solved.
>
> Except on embedded platforms that have garbage CPU's without even a
> cycle counter.
>
> But those won't have spinning rust anyway.
>
> Yes, bad SSD's and MMC disks (that they do have) will generate timing
> noise too, but in the absense of a cycle counter, that noise won't be
> much use.
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.
[We would not want to do that in normal operation, for obvious
reasons, just when userland is blocked and waiting for entropy.]
Hmm?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists