Re: Entropy from net devices - keyboard & IDE just as 'bad' (better timing in random.c)

["Johan Adolfsson" <johan.adolfsson@axis.com>]

Alex Bligh - linux-kernel <linux-kernel@alex.org.uk> wrote:

> Well, I was arguing that network traffic was sufficiently unobservable
> that it constitutes valid entropy under some circumstances, until I went
> and read the code. It is so (it seems to me) on some i386 versions, where
> the cycle clock is used. It is definitely not (and neither are any of
> the other interrupt timings) where jiffies are used, for a start
> because /proc/interrupts gives you the jiffie count (timer interrupts)
> and the other interrupt counters simultaneously. So my argument is
> that in some situations (where you know are happy with the extent
> to which there is no observation of your wire locally), net IRQs
> are no worse than the other sources of entropy, and sometimes they
> are better (consider keyboards connected by radio). Obviously, in
> cases like 802.11, they are substantially worse (and, no doubt, we
> could omit Robert's patch from things like 802.11 drivers which
> are obvious 'don't do that' cases).

How about improving that with something like this (not test compiled)

static void add_timer_randomness(struct timer_rand_state *state, unsigned
num)
{
 __u32  time;
 __s32  delta, delta2, delta3;
 int  entropy = 0;

#if defined (__i386__)
 if ( test_bit(X86_FEATURE_TSC, &boot_cpu_data.x86_capability) ) {
  __u32 high;
  __asm__(".byte 0x0f,0x31"
   :"=a" (time), "=d" (high));
  num ^= high;
 } else {
  time = jiffies;
 }
#else
+ struct timeval tv;
+ do_gettimeofday(&tv);
+ num ^= tv.tv_usec;
 time = jiffies;
#endif

Of course do_gettimeofday() is probably a little to heavyweigt for doing
this,
so how about adding an arch specific macro:
GET_JIFFIES_USEC()
that returns the number of microseconds in the current jiffie and simply
use that to modify the num?

/Johan