All of lore.kernel.org
 help / color / mirror / Atom feed
* /dev/random lacks entropy on sparc64
@ 2004-08-09 22:59 Richard Mortimer
  2004-08-09 23:20 ` David S. Miller
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: Richard Mortimer @ 2004-08-09 22:59 UTC (permalink / raw)
  To: sparclinux

Whilst creating a new gpg key I noticed that there is typically very
little entropy in /dev/random.

cat /proc/sys/kernel/random/entropy_avail

was always showing numbers < 100. After a bit of digging I worked out
that this was due to add_timer_randomness() using jiffies to measure
time rather than a hires timesource (i386 and x86_64 use tsc). I knocked
the following patch and have tried this on 2.4.26 and this solves the
problem. 

I suspect that the patch needs some more work (probably shouldn't use
assembly directly in drivers/char/random.c). I'm not sure whether we
should really be calling something like tick_ops->get_tick(). But
actually tick_get_tick() would probably be appropriate on all machines
because we know that %tick is available on all v9 machines and
/dev/random doesn't absolutely need a common tick value across all cpus.

How does this sound?

Richard


shirehall:/tmp# diff -u linux-2.4.26.orig/drivers/char/random.c
linux-2.4.26/drivers/char/random.c
--- linux-2.4.26.orig/drivers/char/random.c     2004-02-18
13:36:31.000000000 +0000
+++ linux-2.4.26/drivers/char/random.c  2004-08-04 00:38:04.000000000
+0100
@@ -750,6 +750,17 @@
        __u32 high;
        rdtsc(time, high);
        num ^= high;
+#elif defined (__sparc_v9__)
+        unsigned long tmp;
+       unsigned high;
+
+        __asm__ __volatile__("rd        %%tick, %0\n\t"
+                             "srlx      %0, 32, %1\n\t"
+                             "srl       %1, 1, %1"
+                             : "=r" (tmp), "=r" (high));
+
+       time = (unsigned)tmp;
+       num ^= high;
 #else
        time = jiffies;
 #endif



-- 
richm@oldelvet.org.uk


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: /dev/random lacks entropy on sparc64
  2004-08-09 22:59 /dev/random lacks entropy on sparc64 Richard Mortimer
@ 2004-08-09 23:20 ` David S. Miller
  2004-08-10  0:06 ` Richard Mortimer
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: David S. Miller @ 2004-08-09 23:20 UTC (permalink / raw)
  To: sparclinux

On Mon, 09 Aug 2004 23:59:20 +0100
Richard Mortimer <richm@oldelvet.org.uk> wrote:

> I suspect that the patch needs some more work (probably shouldn't use
> assembly directly in drivers/char/random.c). I'm not sure whether we
> should really be calling something like tick_ops->get_tick().

I think we should.  Also, you forgot to shift down the
high bits before xor'ing it into 'num'.

I would use this patch.

=== drivers/char/random.c 1.19 vs edited ==--- 1.19/drivers/char/random.c	2003-12-12 07:18:03 -08:00
+++ edited/drivers/char/random.c	2004-08-09 16:04:44 -07:00
@@ -750,6 +750,11 @@
 	__u32 high;
 	rdtsc(time, high);
 	num ^= high;
+#elif defined (__sparc_v9__)
+	unsigned long tick = tick_ops->get_tick();
+
+	time = (unsigned int) tick;
+	num ^= (tick >> 32UL);
 #else
 	time = jiffies;
 #endif

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: /dev/random lacks entropy on sparc64
  2004-08-09 22:59 /dev/random lacks entropy on sparc64 Richard Mortimer
  2004-08-09 23:20 ` David S. Miller
@ 2004-08-10  0:06 ` Richard Mortimer
  2004-08-10  0:28 ` David S. Miller
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: Richard Mortimer @ 2004-08-10  0:06 UTC (permalink / raw)
  To: sparclinux

On Tue, 2004-08-10 at 00:20, David S. Miller wrote:
> On Mon, 09 Aug 2004 23:59:20 +0100
> Richard Mortimer <richm@oldelvet.org.uk> wrote:
> 
> > I suspect that the patch needs some more work (probably shouldn't use
> > assembly directly in drivers/char/random.c). I'm not sure whether we
> > should really be calling something like tick_ops->get_tick().
> 
> I think we should.
Fair enough.

>   Also, you forgot to shift down the
> high bits before xor'ing it into 'num'.
> 
I didn't think that I did :-)

+        __asm__ __volatile__("rd        %%tick, %0\n\t"
+                             "srlx      %0, 32, %1\n\t"
+                             "srl       %1, 1, %1"
+                             : "=r" (tmp), "=r" (high));

The srlx would have done the shift and srl clears out the npt bit.

That's all academic anyway. I tested your patch and it all works great.

> I would use this patch.
> 

Thanks

Richard

-- 
richm@oldelvet.org.uk


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: /dev/random lacks entropy on sparc64
  2004-08-09 22:59 /dev/random lacks entropy on sparc64 Richard Mortimer
  2004-08-09 23:20 ` David S. Miller
  2004-08-10  0:06 ` Richard Mortimer
@ 2004-08-10  0:28 ` David S. Miller
  2004-08-10 16:23 ` Anton Blanchard
  2004-08-10 17:55 ` David S. Miller
  4 siblings, 0 replies; 6+ messages in thread
From: David S. Miller @ 2004-08-10  0:28 UTC (permalink / raw)
  To: sparclinux

On Tue, 10 Aug 2004 01:06:10 +0100
Richard Mortimer <richm@oldelvet.org.uk> wrote:

> >   Also, you forgot to shift down the
> > high bits before xor'ing it into 'num'.
> > 
> I didn't think that I did :-)

Indeed, you're right :-)

> The srlx would have done the shift and srl clears out the npt bit.

FWIW, we never set npt under Linux.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: /dev/random lacks entropy on sparc64
  2004-08-09 22:59 /dev/random lacks entropy on sparc64 Richard Mortimer
                   ` (2 preceding siblings ...)
  2004-08-10  0:28 ` David S. Miller
@ 2004-08-10 16:23 ` Anton Blanchard
  2004-08-10 17:55 ` David S. Miller
  4 siblings, 0 replies; 6+ messages in thread
From: Anton Blanchard @ 2004-08-10 16:23 UTC (permalink / raw)
  To: sparclinux


> Whilst creating a new gpg key I noticed that there is typically very
> little entropy in /dev/random.
> 
> cat /proc/sys/kernel/random/entropy_avail
> 
> was always showing numbers < 100. After a bit of digging I worked out
> that this was due to add_timer_randomness() using jiffies to measure
> time rather than a hires timesource (i386 and x86_64 use tsc). I knocked
> the following patch and have tried this on 2.4.26 and this solves the
> problem. 
> 
> I suspect that the patch needs some more work (probably shouldn't use
> assembly directly in drivers/char/random.c). I'm not sure whether we
> should really be calling something like tick_ops->get_tick(). But
> actually tick_get_tick() would probably be appropriate on all machines
> because we know that %tick is available on all v9 machines and
> /dev/random doesn't absolutely need a common tick value across all cpus.

I remembered Arnd had a patch to use get_cycles(), this way we avoid
each architecture defining their own method. How does this look?

Anton

--

From: Arnd Bergmann <arnd@arndb.de>
To: linux-kernel@vger.kernel.org
Subject: Using get_cycles for add_timer_randomness
Date:	Sat, 16 Aug 2003 03:03:17 +0200

I noticed that only i386 and x86-64 are currently using
a high resolution timer source when adding randomness.
Since many architectures have a working get_cycles()
implementation, it seems rather straightforward to use
that.

Has this been discussed before, or can anyone comment
on the implementation below?

This patch attempts to take into account the size of
cycles_t, which is either 32 or 64 bits wide but
independent of the architecture's word size.

The behavior should be nearly identical to the
old one on i386, x86-64 and all architectures
without a time stamp counter, while finding
more entropy on the other architectures.

	Arnd <><

=== drivers/char/random.c 1.35 vs edited ==--- 1.35/drivers/char/random.c	Wed Aug  6 19:59:31 2003
+++ edited/drivers/char/random.c	Sat Aug 16 02:05:34 2003
@@ -711,8 +711,8 @@
 
 /* There is one of these per entropy source */
 struct timer_rand_state {
-	__u32		last_time;
-	__s32		last_delta,last_delta2;
+	cycles_t	last_time;
+	long		last_delta,last_delta2;
 	int		dont_count_entropy:1;
 };
 
@@ -729,27 +729,28 @@
  * The number "num" is also added to the pool - it should somehow describe
  * the type of event which just happened.  This is currently 0-255 for
  * keyboard scan codes, and 256 upwards for interrupts.
- * On the i386, this is assumed to be at most 16 bits, and the high bits
- * are used for a high-resolution timer.
+ * This is assumed to be at most 16 bits, and the high bits are used for
+ * high-resolution timers.
  *
  */
 static void add_timer_randomness(struct timer_rand_state *state, unsigned num)
 {
-	__u32		time;
-	__s32		delta, delta2, delta3;
+	cycles_t	time;
+	long		delta, delta2, delta3;
 	int		entropy = 0;
 
-#if defined (__i386__) || defined (__x86_64__)
-	if (cpu_has_tsc) {
-		__u32 high;
-		rdtsc(time, high);
-		num ^= high;
+	/*
+	 * Use get_cycles() if implemented, otherwise fall back to
+	 * jiffies.
+	 */
+	time = get_cycles();
+	if (time != 0) {
+		if (sizeof (time) > 4) {
+			num ^= (u32)(time >> 32);
+		}
 	} else {
 		time = jiffies;
 	}
-#else
-	time = jiffies;
-#endif
 
 	/*
 	 * Calculate number of bits of randomness we probably added.
=== include/asm-i386/timex.h 1.5 vs edited ==--- 1.5/include/asm-i386/timex.h	Mon Jun  9 14:41:23 2003
+++ edited/include/asm-i386/timex.h	Sat Aug 16 02:17:05 2003
@@ -7,7 +7,7 @@
 #define _ASMi386_TIMEX_H
 
 #include <linux/config.h>
-#include <asm/msr.h>
+#include <asm/processor.h>
 
 #ifdef CONFIG_X86_PC9800
    extern int CLOCK_TICK_RATE;
@@ -44,14 +44,17 @@
 
 static inline cycles_t get_cycles (void)
 {
+	unsigned long long ret=0;
+
 #ifndef CONFIG_X86_TSC
-	return 0;
-#else
-	unsigned long long ret;
+	if (!cpu_has_tsc)
+		return 0;
+#endif
 
+#if defined(CONFIG_X86_GENERIC) || defined(CONFIG_X86_TSC)
 	rdtscll(ret);
-	return ret;
 #endif
+	return ret;
 }
 
 extern unsigned long cpu_khz;

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: /dev/random lacks entropy on sparc64
  2004-08-09 22:59 /dev/random lacks entropy on sparc64 Richard Mortimer
                   ` (3 preceding siblings ...)
  2004-08-10 16:23 ` Anton Blanchard
@ 2004-08-10 17:55 ` David S. Miller
  4 siblings, 0 replies; 6+ messages in thread
From: David S. Miller @ 2004-08-10 17:55 UTC (permalink / raw)
  To: sparclinux

On Wed, 11 Aug 2004 02:23:04 +1000
Anton Blanchard <anton@samba.org> wrote:

> I remembered Arnd had a patch to use get_cycles(), this way we avoid
> each architecture defining their own method. How does this look?

Looks fine to me, someone should push this to Linus.
:-)

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2004-08-10 17:55 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-08-09 22:59 /dev/random lacks entropy on sparc64 Richard Mortimer
2004-08-09 23:20 ` David S. Miller
2004-08-10  0:06 ` Richard Mortimer
2004-08-10  0:28 ` David S. Miller
2004-08-10 16:23 ` Anton Blanchard
2004-08-10 17:55 ` David S. Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.