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
signature.asc
Description: Digital signature
