Re: Intel 820 RNG
On Tue, 5 Mar 2002, Mark Murray wrote: We did make some enhancements that serve our needs, but may not be best for everyone. We actually need entropy in quantity since we could be doing a lot of crypto operations back to back and it can easily become our worst bottleneck. Have you looked at the Yarrow algorithm? Yes. I actually grilled you a bit about this at BSDCon 2000. :-) AFAIK, it will never be back ported to 4-STABLE. Is there an option that's appeared for FreeBSD besides this in the last 18 months? In CURRENT, I have implemented Yarrow to achieve just this purpose. The drawback to our approach is that it can spend a lot of time in the kernel. To tune this behavior we added a few sysctl's. The start/stop script after the diff's tweaks a few of these settings after boot up. Again, look at current. The RNG is _really_ fast. I know. I know. I wish we could use it. Unfortunately this is for an appliance type application and I just don't feel comfortably shipping -CURRENT as product. I'm only just now making the effort to get up to speed on -CURRENT so that we can be ready to use it later this year. Adrian -- [ [EMAIL PROTECTED] ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
Again, look at current. The RNG is _really_ fast. I know. I know. I wish we could use it. Unfortunately this is for an appliance type application and I just don't feel comfortably shipping -CURRENT as product. I'm only just now making the effort to get up to speed on -CURRENT so that we can be ready to use it later this year. Also - have you looked at STABLE's /dev/urandom? M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
On Mon, 4 Mar 2002, Terry Lambert wrote:
Mark Murray wrote:
But, back to the topic. We have taken the OpenBSD driver for the
RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to
FreeBSD-4.4. We made some enhancements to get more of the available random
data bandwidth.
We want to clean them up a little and submit them as a PR, but have
not had time to. If you're interested I can send you the patches and you
can give them a try.
Hi.
Please send me what you have.
Agreed. Anything that stops the harvesting entropy from
sitting in the interrupt processing path for the most
important interrupts on the box can only be a good thing.
-- Terry
I thought some one out there would be interested...
Attached are our diffs relative to 4.4-RELEASE. They are mostly a
direct port of the OpenBSD drivers and their integration into the stock
random device entropy pool.
We did make some enhancements that serve our needs, but may not be
best for everyone. We actually need entropy in quantity since we could be
doing a lot of crypto operations back to back and it can easily become our
worst bottleneck.
To this end, we have an entropy buffer in kernel memory that pulls
large blocks of entropy from the RNG if it's going to read from it at all.
The device puts out several orders of magnitude more entropy than the
original drivers captured, and we needed as much as we could grab.
Ideally we would not mix the entropy into the entropy pool and just use the
high quality entropy from the buffer, but we decided to minimize divergence
from the original sources and not switch to 100% hardware entropy.
The drawback to our approach is that it can spend a lot of time in
the kernel. To tune this behavior we added a few sysctl's. The start/stop
script after the diff's tweaks a few of these settings after boot up.
I cc'd Kaj Groner, who actually did the work for us. He's not on
this list, so don't drop his address. I was more involved at the higher
levels of what we needed to get done when we rebased our appliance from
OpenBSD to FreeBSD last Summer.
cheers,
Adrian
--
[ [EMAIL PROTECTED] ]
--- i386/isa/ic/i82802.hWed Oct 17 12:44:23 2001
+++ i386/isa/ic/i82802.hMon Oct 8 11:55:22 2001
@@ -0,0 +1,21 @@
+/* This is where the first 82802 firmware hub is found. */
+#define FWH_BASE0xffb0
+
+/* This is the offset where the RNG is found. */
+#define RNG_OFFSET 0xc015f
+
+/* Number of RNG ports */
+#define RNG_SPAN3
+
+/* RNG registers */
+#define RNG_HWSTAT 0x00
+#define RNG_DATASTAT0x01
+#define RNG_DATA0x02
+
+/* RNG hardware status register (RNG_HWSTAT) */
+#define RNG_PRESENT 0x40
+#define RNG_ENABLED 0x01
+
+/* RNG data status register (RNG_DATASTAT) */
+#define RNG_READY 0x01
+
--- kern/kern_random.c.orig Sun Oct 28 16:06:31 2001
+++ kern/kern_random.c Sun Oct 28 16:06:49 2001
@@ -224,20 +224,41 @@
/* Prevent overflow */
if (r-entropy_count POOLBITS)
r-entropy_count = POOLBITS;
if (r-entropy_count = 8)
selwakeup(random_state.rsel);
}
void
+add_true_randomness(u_int32_t num)
+{
+add_entropy_word(random_state, num);
+
+random_state.entropy_count += sizeof (num) * 8;
+
+ /* Prevent overflow */
+ if (random_state.entropy_count POOLBITS)
+ random_state.entropy_count = POOLBITS;
+
+ if (random_state.entropy_count = 8)
+ selwakeup(random_state.rsel);
+}
+
+u_int
+get_entropy_deficit(void)
+{
+return (POOLBITS - random_state.entropy_count);
+}
+
+void
add_keyboard_randomness(u_char scancode)
{
add_timer_randomness(random_state, keyboard_timer_state, scancode);
}
void
add_interrupt_randomness(void *vsc)
{
int intr;
struct random_softc *sc = vsc;
--- pci/pcisupport.c15 Aug 2001 04:04:59 - 1.154.2.7
+++ pci/pcisupport.c22 Oct 2001 18:39:54 -
@@ -48,7 +48,15 @@
#include sys/systm.h
#include sys/malloc.h
#include sys/kernel.h
+
+#include machine/resource.h
+#include machine/bus.h
+#include machine/clock.h
+
+#include sys/rman.h
#include sys/bus.h
+#include sys/random.h
+#include sys/sysctl.h
#include pci/pcivar.h
#include pci/pcireg.h
@@ -57,6 +65,8 @@
#include vm/vm_object.h
#include vm/pmap.h
+#include i386/isa/ic/i82802.h
+
/*-
**
** Intel chipsets for 486 / Pentium processor
@@ -669,6 +679,170 @@
return descr;
}
+#define RNG_RESERVE 0x1
+
+struct pcib_softc {
+ /* RNG stuff */
+ struct {
+int rid;
+struct resource *res;
+bus_space_tag_t bt;
+bus_space_handle_t bh;
+
+struct callout_handle toh;
+
+u_int8_t reserve[RNG_RESERVE];
+int reserve_start, reserve_end;
+ }
Re: Intel 820 RNG
On Mon, 4 Mar 2002, Sam Leffler (at Usenix) wrote: But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. I ported the openbsd crypto stuff to -stable for the purpose of making the soekris vpn1211 card usable (Hifn 7951). As part of this I tied the RNG on the Hifn to /dev/random; all that was required was to add a call to inject the data as entropy (or so I believed). Are your diff's available? We have a handful of idle powercrypt cards, which are Hifn's IIRC, idle here, and we have boxes without the i810 entropy device on their motherboards. This would be handy. Did you just dump the entropy into the existing entropy pool of the standard random(4) driver, or does it replace the driver with 100% hardware entropy? What kind of entropy bandwidth are you able to get? cheers, Adrian -- [ [EMAIL PROTECTED] ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
We did make some enhancements that serve our needs, but may not be best for everyone. We actually need entropy in quantity since we could be doing a lot of crypto operations back to back and it can easily become our worst bottleneck. Have you looked at the Yarrow algorithm? To this end, we have an entropy buffer in kernel memory that pulls large blocks of entropy from the RNG if it's going to read from it at all. The device puts out several orders of magnitude more entropy than the original drivers captured, and we needed as much as we could grab. Ideally we would not mix the entropy into the entropy pool and just use the high quality entropy from the buffer, but we decided to minimize divergence from the original sources and not switch to 100% hardware entropy. In CURRENT, I have implemented Yarrow to achieve just this purpose. The drawback to our approach is that it can spend a lot of time in the kernel. To tune this behavior we added a few sysctl's. The start/stop script after the diff's tweaks a few of these settings after boot up. Again, look at current. The RNG is _really_ fast. I cc'd Kaj Groner, who actually did the work for us. He's not on this list, so don't drop his address. I was more involved at the higher levels of what we needed to get done when we rebased our appliance from OpenBSD to FreeBSD last Summer. :-) You may be pleasantly surprised :-) M (Thanks for the sources!) -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Intel 820 RNG
All, Apologies if this has been discussed before. The new Intel i820 motherboard chipset is due to ship with an on-board Random Number Generator (RNG)... are there any plans for us to support this, or does support already exist? thanks BMS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
On Mon, 4 Mar 2002, Bruce M Simpson wrote: All, Apologies if this has been discussed before. The new Intel i820 motherboard chipset is due to ship with an on-board Random Number Generator (RNG)... are there any plans for us to support this, or does support already exist? thanks BMS I haven't had time to keep up with this, so please bear with me. Is the i820 actually a new chipset that includes the RNG? We've been having trouble getting boards that have the RNG capabilities, and I have been told by the person doing the research that Intel seemed to be dropping this feature from the newer chipsets. If not, then I'm most pleased to be corrected and would like some references that I can throw at someone until they find us the proper motherboards again for our product. But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Adrian -- [ [EMAIL PROTECTED] ] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Hi. Please send me what you have. Thanks! M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. I ported the openbsd crypto stuff to -stable for the purpose of making the soekris vpn1211 card usable (Hifn 7951). As part of this I tied the RNG on the Hifn to /dev/random; all that was required was to add a call to inject the data as entropy (or so I believed). Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
Mark Murray wrote: But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Hi. Please send me what you have. I thought it was an add-on to the firmware hub rather than the 820 chipset proper. The firmware hubs seems to be just about everywhere these days on intel chipset motherboards.. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Intel 820 RNG
Mark Murray wrote: But, back to the topic. We have taken the OpenBSD driver for the RNG on the i810 chipset (and some other i8x0 chipsets), and ported it to FreeBSD-4.4. We made some enhancements to get more of the available random data bandwidth. We want to clean them up a little and submit them as a PR, but have not had time to. If you're interested I can send you the patches and you can give them a try. Hi. Please send me what you have. Agreed. Anything that stops the harvesting entropy from sitting in the interrupt processing path for the most important interrupts on the box can only be a good thing. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
