Mailinglist Archive: opensuse-kernel (77 mails)

< Previous Next >
[opensuse-kernel] Fate #306591: entropy daemons in 11.2 - Kernel Removal IRQF_SAMPLE_RANDOM
  • From: Rob OpenSuSE <rob.opensuse.linux@xxxxxxxxxxxxxx>
  • Date: Mon, 7 Dec 2009 11:58:02 +0000
  • Message-id: <ce9d8ed60912070358u2a78c071oa4eaa612dea255c7@xxxxxxxxxxxxxx>
I have taken an interest in Fate #306591
https://features.opensuse.org/306591 Andreas Jaeger has mused on
community volunteer to package something. Now, I took a look at few
suggestions, but 2 of them weren't "just work" in sense that they
required webcam or mic, which seems like a possible can of worms to
me.

So I wondered about using timing jitter from user space? As a
prototype I've knocked up short piece of C, which uses calls :

nanosleep( &tsleep, 0);
clock_gettime(CLOCK_REALTIME, &ttnow)

This has been tested on i686 Athlon MP & P4 (Celeron Willamette) and
x86_64 Athlon 64 x2; and I do appear to get a useful amount of
unpredictable bits from this, even if the raw timings are not random.

The timing jitter provides an externally unobservable measurement, and
would allow sysadmin to tune to some extent eg) run 10 times/s
(80bits/s) - 25 times/s (400bits/s).

If this sounds like a useful approach, then I'd propose to continue on
and develop a small daemon which gathers entropy bits from timing
unpredictabilities caused by scheduler & interrupts, and also
periodically gathers extra entropy (especially on startup) borrowing
from techniques uses in the perl egd daemon (which would need
modifying in any case).

Obviously I'm a bit concerned about any move on power saving, this
would obviously requires N wake ups, perhaps precautions would be
needed to avoid them getting squeezed together by power saving patches
which aim to batch up, code that sleeps like this?

Rob
--
To unsubscribe, e-mail: opensuse-kernel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-kernel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups