[opensuse-kernel] Fate #306591: entropy daemons in 11.2 - Kernel Removal IRQF_SAMPLE_RANDOM
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@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Mon, Dec 07, 2009 at 11:58:02AM +0000, Rob OpenSuSE wrote:
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?
Most of the stuff running in the system is not a good enough random source. Geting input from a true noise source would be more helpful, like from TPMs. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
2009/12/10 Marcus Meissner
On Mon, Dec 07, 2009 at 11:58:02AM +0000, Rob OpenSuSE wrote:
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.
Most of the stuff running in the system is not a good enough random source.
Geting input from a true noise source would be more helpful, like from TPMs.
Yes, perhaps if the kernel team have drivers for TPM & TRNG's their high quality source of entropy could be incorporated. Unfortunately any contribution I make on this feature, needs to be less ambitious if I am to get a positive result in a reasonable amount of time. Perhaps an ability to configure the daemon for reading from an SSL socket, or a local device, for better entropy sources where they are available, would allow incorporation of such sources? Mixed in with clock jitter and system events, even a central daemon reading from CDR of prepared random numbers, is likely to be a practical solution to the problem, for a network of diskless hosts. As it stands, yes, I could put a mic near my fan outlet, I can use a webcam, but they have potential privacy concerns, in addition to being in way of normal use of the machine. That's the core reason I'm looking from the EGD system files and clock jitter angle at moment. Thanks for the feedback, any attempt to provide entropy from user space needs scrutiny due to the security implications Rob -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (2)
-
Marcus Meissner -
Rob OpenSuSE