Re: [PATCH] (0/4) Entropy accounting fixes

From: Oliver Xymoron (
Date: Sun Aug 18 2002 - 12:31:40 EST

On Sun, Aug 18, 2002 at 09:59:41AM -0700, Linus Torvalds wrote:
> On Sun, 18 Aug 2002, Oliver Xymoron wrote:
> >
> > The key word is actually conservative, as in conservative estimate.
> > Conservative here means less than or equal to.
> Your argument is that even with a gigahz logic analyzer on the network
> line, you should certainly see randomness that is worth considering.
> I dare you to actually show perfect correlation from it: the interrupt may
> be synchronized to the PCI clock, but the code executed there-after
> certainly will not. And even if the machine is 100% idle, and the whole
> working set fits in the L1 cache, the DMA generated by the packet itself
> will result in cache invalidations.
> In other words, in order for you to actually be able to predict the TSC
> from the outside, you'd have to not just have the gigahz logic analyzer on
> the network line, you' dalso have to be able to correlate the ethernet
> heartbeat to the PCI clock (which you probably could do by looking at the
> timing of the reply packets from a ping flood, although it would be
> "interestng" to say the least and probably depends on how the network card
> generates the ethernet clock), _and_ you'd have to be able to do a cache
> eviction analysis (which in turn requires knowing the initial memory
> layout for the kernel data structures for networking).

Yes, obviously 'nontrivial'. But then so are sideband attacks on smart
> And your argument that there is zero randomness in the TSC _depends_ on
> your ability to perfectly estimate what the TSC is. If you cannot do it,
> there is obviously at least one bit of randomness there. So I don't think
> your "zero" is a good conservative estimate.

Have you seen my compromise patch yet? I think this (or something like
it) should make us both happy.

diff -ur a/drivers/char/random.c b/drivers/char/random.c
--- a/drivers/char/random.c 2002-08-17 20:54:02.000000000 -0500
+++ b/drivers/char/random.c 2002-08-18 01:38:58.000000000 -0500
@@ -724,6 +724,7 @@
 static int benford[16]={0,0,0,1,2,3,4,5,5,6,7,7,8,9,9,10};
 static int last_ctxt=0;
+static int trust_break=50, trust_pct=0, trust_min=0, trust_max=100;
 void add_timing_entropy(void *src, unsigned datum)
@@ -764,6 +765,18 @@
                 bits=benford[int_log2_16bits(delta & 0xffff)];
+ /* Throw in an untrusted bit as entropy trust_pct% of the time */
+ if(trust_pct && !bits)
+ {
+ trust_break+=trust_pct;
+ if(trust_break>=100)
+ {
+ bits=1;
+ trust_break-=100;
+ }
+ }
         batch_entropy_store(datum^time, bits);
@@ -1779,6 +1792,10 @@
         {RANDOM_UUID, "uuid",
          NULL, 16, 0444, NULL,
          &proc_do_uuid, &uuid_strategy},
+ {RANDOM_TRUST_PCT, "trust_pct",
+ &trust_pct, sizeof(int), 0644, NULL,
+ &proc_dointvec_minmax, &sysctl_intvec, 0,
+ &trust_min, &trust_max},
diff -ur a/include/linux/sysctl.h b/include/linux/sysctl.h
--- a/include/linux/sysctl.h 2002-08-17 00:30:00.000000000 -0500
+++ b/include/linux/sysctl.h 2002-08-18 01:37:54.000000000 -0500
@@ -182,7 +182,8 @@
 /* /proc/sys/bus/isa */

> [ Side note: the most common source of pseudo-random numbers is the old
> linear congruental generator, which really is a sampling of a "beat"
> between two frequencies that are supposed to be "close", but prime.
> That's a fairly simple and accepted pseudo-random generator _despite_
> the fact that the two frequencies are totally known, and there is zero
> noise inserted. I'll bet you'll see a _very_ hard-to-predict stream from
> something like the PCI clock / CPU clock thing, with noise inserted
> thanks to things like cache misses and shared bus interactions. Never
> mind the _real_ noise of having a work-load. ]

In practically all modern machines, the CPU clock is driven off the
same source as the PCI clock, the northbus clock, and every other
clock used in the core.

> > No, it says /dev/random is primarily useful for generating large
> > (>>160 bit) keys.
> Which is exactly what something like sshd would want to use for generating
> keys for the machine, right? That is _the_ primary reason to use
> /dev/random.

Sshd doesn't generate large keys, ssh-keygen does.

 "Love the dolphins," she advised him. "Write by W.A.S.T.E.." 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:00:15 EST