ocf-linux-20050315 - Asynchronous Crypto support for linux
Subsystems (4)
Hi all,
The latest release of ocf-linux (20050315) is available for download from the project page:
http://ocf-linux.sourceforge.net/
This release includes the following changes:
* Hifn PLL bug fixes
* Makefile fixes for 2.6 builds
* 2.6.11 and 2.4.29 patches
* cleanups for x86 builds
OCF-Linux is a Linux port of the OpenBSD/FreeBSD Cryptographic Framework (OCF). This port aims to bring full asynchronous HW/SW crypto acceleration to the Linux kernel and applications running under Linux. Results have shown improvements of up to 7 times that of software crypto for bulk crypto throughput using OpenSSL.
At this point in time OCF-Linux provides acceleration for OpenSSL, OpenSSH (scp, ssh, ...) and also supports the BSD crypto testing applications. It can accelerate DES, 3DES, AES, MD5, SHA, and Public Key operations with plans to include Random Number generators and more. This project is being actively developed as a high performance crypto solution for embedded devices but also applies equally well to any linux based server or desktop.
Cheers,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
PATCH 1/1 API for true Random Number Generators to add entropy (2.6.11)
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy.
Cheers,
Davidm
Index: linux-2.6.11/include/linux/random.h
===================================================================
RCS file: linux-2.6.11/include/linux/random.h,v
retrieving revision 1.1.1.6
include/linux/random.h +2 -0
@@ -48,6 +48,8 @@ unsigned int value);extern void add_interrupt_randomness (int irq); +extern void add_true_randomness (__u32 *buf,int nwords); +extern void get_random_bytes (void *buf,int nbytes);void generate_random_uuid (unsigned char uuid_out[16 ]);
Index: linux-2.6.11/drivers/char/random.c
===================================================================
RCS file: linux-2.6.x/drivers/char/random.c,v
retrieving revision 1.1.1.28
drivers/char/random.c +33 -0
@@ -902,6 +902,39 @@EXPORT_SYMBOL (add_disk_randomness); +/* +* provide a mechanism for HW to add entropy that is of +* very good quality from a true random number generator +*/ +void add_true_randomness (__u32 *buf,int nwords) +{ +struct entropy_store *r; +int wakeup_check =0 ; + + +if (!random_state || !sec_random_state) +return ; + +/* +* if we have too much entropy, put some in the secondary pool +*/ + r = random_state; +if (r->entropy_count >= r->poolinfo.POOLBITS) + r = sec_random_state; +else + wakeup_check = (r->entropy_count < random_read_wakeup_thresh); + +add_entropy_words (r, buf, nwords); +credit_entropy_store (r, nwords *32 ); + +/* +* wakeup if we added enough entropy to cross the threshold +*/ +if (wakeup_check && r->entropy_count >= random_read_wakeup_thresh) +wake_up_interruptible (&random_read_wait); +} +EXPORT_SYMBOL (add_true_randomness); +/****************************************************************** * * Hash function definition
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
PATCH 1/1 API for true Random Number Generators to add entropy (2.4.29)
Hi all,
Here is a small patch for 2.4.29 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy.
Cheers,
Davidm
Index: linux-2.4.29/include/linux/random.h
===================================================================
RCS file: /cvs/sw/linux-2.4.29/include/linux/random.h,v retrieving revision 1.1.1.1
retrieving revision 1.3
include/linux/random.h +1 -0
@@ -52,6 +52,7 @@extern void add_mouse_randomness (__u32 mouse_data);extern void add_interrupt_randomness (int irq);extern void add_blkdev_randomness (int major); +extern void add_true_randomness (__u32 *buf,int nwords);extern void get_random_bytes (void *buf,int nbytes);void generate_random_uuid (unsigned char uuid_out[16 ]);
Index: linux-2.4.29/drivers/char/random.c
===================================================================
RCS file: /cvs/sw/linux-2.4.29/drivers/char/random.c,v retrieving revision 1.1.1.9
retrieving revision 1.11
drivers/char/random.c +33 -0
@@ -842,6 +837,39 @@add_timer_randomness (blkdev_timer_state[major],0x200 +major); } +/* +* provide a mechanism for HW RNG's to add entropy that is of +* very good quality. +*/ +void add_true_randomness (__u32 *buf,int nwords) +{ +struct entropy_store *r; +int wakeup_check =0 ; + + +if (!random_state || !sec_random_state) +return ; + +/* +* if we have too much entropy, put some in the secondary pool +*/ + r = random_state; +if (r->entropy_count >= r->poolinfo.POOLBITS) + r = sec_random_state; +else + wakeup_check = (r->entropy_count < random_read_wakeup_thresh); + +add_entropy_words (r, buf, nwords); +credit_entropy_store (r, nwords *32 ); + +/* +* wakeup if we added enough entropy to cross the threshold +*/ +if (wakeup_check && r->entropy_count >= random_read_wakeup_thresh) +wake_up_interruptible (&random_read_wait); +} +EXPORT_SYMBOL (add_true_randomness); +/****************************************************************** * * Hash function definition
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to David McCulloughQuoted 12 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.
We've already had hardware RNG support for a while now.
No kernel patching needed.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ...
Quoted 13 lines · David McCullough
Quoted 12 lines
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 8 lines
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.We've already had hardware RNG support for a while now.
No kernel patching needed.
Are you talking about /dev/hw_random ? If not then sorry I didn't see it :-(
On a lot of the small systems I work on, /dev/random is completely unresponsive, and all the apps use /dev/random, not /dev/hw_random.
Would you suggest making /dev/random point to /dev/hw_random then ?
Thanks,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 6 lines · David McCullough
Are you talking about
/dev/hw_random? If not then sorry I didn't see it :-(On a lot of the small systems I work on,
/dev/randomis completely unresponsive, and all the apps use/dev/random, not/dev/hw_random.Would you suggest making
/dev/randompoint to/dev/hw_randomthen ?
Or feed the entropy pool from hw_random?
Michal Ludvig
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to David McCulloughQuoted 25 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 13 lines · David McCullough
Quoted 12 lines
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 8 lines
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.We've already had hardware RNG support for a while now.
No kernel patching needed.
Quoted 6 lines
Are you talking about
/dev/hw_random? If not then sorry I didn't see it :-(On a lot of the small systems I work on,
/dev/randomis completely unresponsive, and all the apps use/dev/random, not/dev/hw_random.Would you suggest making
/dev/randompoint to/dev/hw_randomthen ?
All the apps are supposed to use /dev/random, so that's correct.
For Hardware RNGs, userspace rngd daemon obtains entropy, checks it (mainly checking for hardware failures), and then stuffs entropy into the kernel random device. http://sf.net/projects/gkernel/
On the "to do" list is making rngd directly generate entropy use 'xstore' on VIA CPUs, rather than going kernel -> userland -> kernel.
Also, there are other entropy daemons floating about. I think there is one that obtains noise from an audio device.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 2 lines
Also, there are other entropy daemons floating about. I think there is one that obtains noise from an audio device.
That's correct: http://www.vanheusden.com/aed/ audio-entropyd
There's also one for doing the same with video4linux devices:
http://www.vanheusden.com/ved/
Folkert van Heusden
Auto te koop! Zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+------------------------------------------------------------------+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See | |http://vanheusden.com/multitail/features.html for a feature list. | +------------------------------------------= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikJivin Jeff Garzik lays it down ...
Quoted 29 lines
Quoted 28 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 13 lines · David McCullough
Quoted 12 lines
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 8 lines
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.We've already had hardware RNG support for a while now.
No kernel patching needed.
Are you talking about
/dev/hw_random? If not then sorry I didn't see it :-(
Quoted 6 lines
Quoted 4 lines
On a lot of the small systems I work on,
/dev/randomis completely unresponsive, and all the apps use/dev/random, not/dev/hw_random.Would you suggest making
/dev/randompoint to/dev/hw_randomthen ?All the apps are supposed to use
/dev/random, so that's correct.
Ok
Quoted 9 lines
For Hardware RNGs, userspace rngd daemon obtains entropy, checks it (mainly checking for hardware failures), and then stuffs entropy into
the kernel random device. http://sf.net/projects/gkernel/On the "to do" list is making rngd directly generate entropy use 'xstore' on VIA CPUs, rather than going kernel -> userland -> kernel.
Also, there are other entropy daemons floating about. I think there is one that obtains noise from an audio device.
I had looked at hw_random, but it seemed a little platform specific (x86), and it doesn't currently have a way for RNG providers to register themselves. Admittedly I did not know how it's output was being used in practice.
The drivers I am working with do crypto/public key and RNG. Not all of them can easily have the RNG support taken from the driver and plugged into hw_random.c, since it is (in most cases) a single PCI chip with it's own registers, initialisation and configuration, that, IMO belongs in the driver for the particular chip.
Not that it isn't possible, but hw_random would start supporting a much larger number of HW variants and I think it would get ugly.
It would be possible to add a "register" interface to hw_random so that you can register other RNG's easily. This would seem reasonable.
I work on fairly resource constrained embedded devices a lot of the time, so when I can avoid adding applications and reduce kernel size, I do. Thus my motivation to add a simple API for adding entropy to /dev/random.
Cheers,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 55 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 29 lines
Quoted 27 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 22 lines · David McCullough
Quoted 13 lines
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.We've already had hardware RNG support for a while now.
No kernel patching needed.
Quoted 8 lines
Quoted 6 lines
Are you talking about
/dev/hw_random? If not then sorry I didn't see it :-(On a lot of the small systems I work on,
/dev/randomis completely unresponsive, and all the apps use/dev/random, not/dev/hw_random.Would you suggest making
/dev/randompoint to/dev/hw_randomthen ?All the apps are supposed to use
/dev/random, so that's correct.Ok
Quoted 5 lines
For Hardware RNGs, userspace rngd daemon obtains entropy, checks it (mainly checking for hardware failures), and then stuffs entropy into the kernel random device. http://sf.net/projects/gkernel/
On the "to do" list is making rngd directly generate entropy use 'xstore' on VIA CPUs, rather than going kernel -> userland -> kernel.
Also, there are other entropy daemons floating about. I think there is one that obtains noise from an audio device.
I had looked at
hw_random, but it seemed a little platform specific (x86), and it doesn't currently have a way for RNG providers to register themselves. Admittedly I did not know how it's output was being used in practice.
Quoted 5 lines
The drivers I am working with do
crypto/publickey and RNG. Not all of them can easily have the RNG support taken from the driver and plugged intohw_random.c, since it is (in most cases) a single PCI chip with it's own registers, initialisation and configuration, that, IMO belongs in the driver for the particular chip.
Agreed.
Quoted 2 lines
Not that it isn't possible, but
hw_randomwould start supporting a much larger number of HW variants and I think it would get ugly.
Agreed.
Quoted 2 lines
It would be possible to add a "register" interface to
hw_randomso that you can register other RNG's easily. This would seem reasonable.
Agreed.
Quoted 4 lines
I work on fairly resource constrained embedded devices a lot of the time, so when I can avoid adding applications and reduce kernel size, I do. Thus my motivation to add a simple API for adding entropy to
/dev/random.
We already have the facilities to add entropy, as current use of hw_random+rngd shows.
Jeff
Re: API for true Random Number Generators to add entropy (2.6.11)
In reply to David McCulloughQuoted 2 lines
Would you suggest making
/dev/randompoint to/dev/hw_randomthen ?
No. I for example do not have a hardware RNG, so modprobe hw_random fails with No Such Device. Making it a symlink would make it a dangling one.
Jan Engelhardt
Re: API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Jan Engelhardt
Quoted 2 lines
Would you suggest making
/dev/randompoint to/dev/hw_randomthen ?No. I for example do not have a hardware RNG, so
modprobe hw_randomfails with No Such Device. Making it a symlink would make it a dangling one.
It shouldn't be a symlink. Something like rngd should read from it and feed it into /dev/random's entropy pool.
Dave
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to David McCulloughQuoted 4 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Are we likely to see any in-kernel users of this?
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 9 lines · Andrew Morton
Quoted 3 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Hrm. This is getting pretty lame, if you can't take patches from the -latest- stable release. It's pretty easy in BK:
bk clone -ql -rv2.6.11 linux-2.6 rng-2.6.11
cd rng-2.6.11
{ apply patch }
bk pull ../linux-2.6Can you set up something like that?
Quoted 1 line
Are we likely to see any in-kernel users of this?
We already have a hardware RNG system. This is completely unneeded.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Review
Quoted 13 lines · Jeff Garzik
Quoted 3 lines
It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Hrm. This is getting pretty lame, if you can't take patches from the -latest- stable release. It's pretty easy in BK:
(quoted diff) +0
-0bk clone -ql -rv2.6.11 linux-2.6 rng-2.6.11 cd rng-2.6.11 { apply patch } bk pull ../linux-2.6 Can you set up something like that?
About thirty patches have gone into random.c since 2.6.11. But the patch was easy enough to apply anyway.
And then, it didn't compile. I don't think bk will fix that.
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 13 lines · Andrew Morton
Quoted 12 lines · Jeff Garzik
Quoted 3 lines
It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Hrm. This is getting pretty lame, if you can't take patches from the -latest- stable release. It's pretty easy in BK:
(quoted diff) +0
-0bk clone -ql -rv2.6.11 linux-2.6 rng-2.6.11 cd rng-2.6.11 { apply patch } bk pull ../linux-2.6
Quoted 6 lines
Quoted 1 line
Can you set up something like that?
About thirty patches have gone into
random.csince 2.6.11. But the patch was easy enough to apply anyway.And then, it didn't compile. I don't think bk will fix that.
No, the names of all the pools changed. I agree with Jeff, this patch is unnecessary. If we actually wanted such an interface, I'd rather it refactor things so as not to reproduce the wake up logic.
Signature · 1 line
Mathematics is the supreme nostalgia of our time.
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikQuoted 17 lines · Jeff Garzik
Quoted 10 lines · Andrew Morton
Quoted 3 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Hrm. This is getting pretty lame, if you can't take patches from the -latest- stable release. It's pretty easy in BK:
Quoted 6 lines
bk clone -ql -rv2.6.11 linux-2.6 rng-2.6.11 cd rng-2.6.11 { apply patch } bk pull ../linux-2.6Can you set up something like that?
I thought that the latest stable release was 2.6.11.5.
However, what I really want to do is ask what patches should be made against. I suggested on linux-scsi a day or 2 ago that they should be made against the latest linus-bk (or snapshot) unless the patch only applies to -mm, then they should obviously be made against -mm. 2.6.11 plain is relatively aged IMO also....
Signature · 1 line
~Randy
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Andrew MortonQuoted 10 lines · Andrew Morton
Quoted 4 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Are we likely to see any in-kernel users of this?
Any external crtypto framework can add entropy using that routing. Currently it can be
- OCF
- acrypto
- hw_random.c
hw_random.c already does it using userspace daemons, which is bad idea for very fast HW - like VIA xstore/xcrypt instructions.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 2 lines · Evgeniy Polyakov
hw_random.calready does it using userspace daemons,
which is bad idea for very fast HW - like VIA xstore/xcrypt instructions.
This is incorrect, because it implies that a user would want to use the 'xstore' feature at full speed -- which would dominate the CPU, drastically slowing down the applications that are actually doing work.
As I mentioned in another message, VIA xstore support should be removed from hw_random.c and moved completely to userspace rngd.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 8 lines · Jeff Garzik
Quoted 3 lines · Evgeniy Polyakov
hw_random.calready does it using userspace daemons, which is bad idea for very fast HW - like VIA xstore/xcrypt instructions.This is incorrect, because it implies that a user would want to use the 'xstore' feature at full speed -- which would dominate the CPU, drastically slowing down the applications that are actually doing work.
If user want to get RNG data at full speed we do not want to allow it? Something changed in the world...
User actually do not want to use xstore, but only read from /dev/random.
If kernelspace can assist and driver _knows_ in advance that data produced is cryptographically strong, why not allow it directly access pools?
Quoted 5 lines
As I mentioned in another message, VIA xstore support should be removed from
hw_random.cand moved completely to userspace rngd.Jeff
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 4 lines · Evgeniy Polyakov
Quoted 2 lines · Jeff Garzik
Evgeniy Polyakov wrote:
Quoted 8 lines
Quoted 4 lines
Quoted 2 lines
hw_random.calready does it using userspace daemons,
which is bad idea for very fast HW - like VIA xstore/xcrypt instructions.This is incorrect, because it implies that a user would want to use the 'xstore' feature at full speed -- which would dominate the CPU, drastically slowing down the applications that are actually doing work.
If user want to get RNG data at full speed we do not want to allow it? Something changed in the world...
I agree with this sentiment; this is mainly a policy decision that kernel programmers should not make.
Certainly _by default_ the RNG should not be run "full blast" all the time. This is a needless CPU soaker.
This is another example of why the userspace rngd is useful: it is trivial to implement "CPU soaker" policy if you wish, or use the default "don't eat all my CPU" policy.
Quoted 1 line
User actually do not want to use xstore, but only read from
/dev/random.
That's a policy decision to be made by the user, not you.
Some users may wish to use RNG directly.
Quoted 3 lines
If kernelspace can assist and driver _knows_ in advance that data produced is cryptographically strong, why not allow it directly access pools?
A kernel driver cannot know in advance that the data from a hardware RNG is truly random, unless the data itself is 100% validated beforehand.
Jeff
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 3 lines · Jeff Garzik
I agree with this sentiment; this is mainly a policy decision that kernel programmers should not make.
Exactly. Policy decisions like this as well as entropy checking should be done in user-space.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikJivin Jeff Garzik lays it down ...
...
Quoted 6 lines
Quoted 3 lines
If kernelspace can assist and driver _knows_ in advance that data produced is cryptographically strong, why not allow it directly access pools?
A kernel driver cannot know in advance that the data from a hardware RNG is truly random, unless the data itself is 100% validated beforehand.
You can also say that it cannot know that data written to /dev/random is truly random unless it is also validated ?
For argument you could just run "cat < /dev/hwrandom > /dev/random" instead of using rngd.
If /dev/random demands a level of randomness, shouldn't it enforce it ?
If the HW is using 2 random sources, a non-linear mixer and a FIPS140 post processor before handing you a random number it would be nice to take advantage of that IMO.
Cheers,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for TRNG (2.6.11) [Fortuna]
Quoted 13 lines · David McCullough
Jivin Jeff Garzik lays it down ...
...Quoted 6 lines
Quoted 3 lines
If kernelspace can assist and driver _knows_ in advance that data produced is cryptographically strong, why not allow it directly access pools?
A kernel driver cannot know in advance that the data from a hardware RNG is truly random, unless the data itself is 100% validated beforehand.
You can also say that it cannot know that data written to
/dev/randomis truly random unless it is also validated ?
Quoted 8 lines
For argument you could just run "cat <
/dev/hwrandom>/dev/random" instead of using rngd.If
/dev/randomdemands a level of randomness, shouldn't it enforce it ?If the HW is using 2 random sources, a non-linear mixer and a FIPS140 post processor before handing you a random number it would be nice to take advantage of that IMO.
For those who are interested, my Fortuna patch to the Linux RNG (/dev/random, /dev/urandom) is available here (2.6.12-rc1, works on kernels as low as 2.6.11.4):
http://jlcooke.ca/random/
Fortuna is a Cryptographically Secure Random Number Generator (CSRNG) developed by Neils Ferguson and Bruce Schnier and published in their book Applied Cryptography.
By most regards, it is the state of the art as far as software based CSRNGs go. The website gives an over view of the design, here is a summary:
Fortuna uses a block cipher (AES128) in CTR mode to generate output. Fortuna uses a 32 hash states (SHA-256) which collect event data from sources of randomness (as usual in Linux).
Once every 0.1sec or so, some of the hash states are finalised and the digests are collected.
These digests are hashed together with with the current block cipher key to produce the new block cipher key.
Ferguson goes into detail in Practical Cryptography as to why this design is superior to Yarrow based RNG (like the existing Linux RNG) and also delves into why entropy estimation is impossible and is infact a liability in RNG design.
My patch keep the entropy estimation from the current Linux RNG since this is a very controversial issue with most people. Disabling entropy estimation and /dev/random blocking can be done by changing the RANDOM_NO_ENTROPY_COUNT macro to 1.
I have not tested the syncookie code yet. But networking works smoothly after I echo "1" to /proc/sys/net/ipv4/tcp_syncookies. Any help on this would be great.
JLC
Re: [PATCH] API for TRNG (2.6.11) [Fortuna]
Patch attached.
JLC
Quoted 57 lines · Jean-Luc Cooke
Quoted 13 lines · David McCullough
Jivin Jeff Garzik lays it down ...
...Quoted 6 lines
Quoted 3 lines
If kernelspace can assist and driver _knows_ in advance that data produced is cryptographically strong, why not allow it directly access pools?
A kernel driver cannot know in advance that the data from a hardware RNG is truly random, unless the data itself is 100% validated beforehand.
You can also say that it cannot know that data written to
/dev/randomis truly random unless it is also validated ?Quoted 8 lines
For argument you could just run "cat <
/dev/hwrandom>/dev/random" instead of using rngd.If
/dev/randomdemands a level of randomness, shouldn't it enforce it ?If the HW is using 2 random sources, a non-linear mixer and a FIPS140 post processor before handing you a random number it would be nice to take advantage of that IMO.
For those who are interested, my Fortuna patch to the Linux RNG (
/dev/random,/dev/urandom) is available here (2.6.12-rc1, works on kernels as low as 2.6.11.4):
http://jlcooke.ca/random/Fortuna is a Cryptographically Secure Random Number Generator (CSRNG) developed by Neils Ferguson and Bruce Schnier and published in their book Applied Cryptography.
By most regards, it is the state of the art as far as software based CSRNGs go. The website gives an over view of the design, here is a summary:
Fortuna uses a block cipher (AES128) in CTR mode to generate output. Fortuna uses a 32 hash states (SHA-256) which collect event data from sources of randomness (as usual in Linux).
Once every 0.1sec or so, some of the hash states are finalised and the digests are collected.
These digests are hashed together with with the current block cipher key to produce the new block cipher key.Ferguson goes into detail in Practical Cryptography as to why this design is superior to Yarrow based RNG (like the existing Linux RNG) and also delves into why entropy estimation is impossible and is infact a liability in RNG design.
My patch keep the entropy estimation from the current Linux RNG since this is a very controversial issue with most people. Disabling entropy estimation and
/dev/randomblocking can be done by changing theRANDOM_NO_ENTROPY_COUNTmacro to 1.I have not tested the syncookie code yet. But networking works smoothly after I echo "1" to
/proc/sys/net/ipv4/tcp_syncookies. Any help on this would be great.
Quoted 5 lines
JLC
_______________________________________________Subscription: http://lists.logix.cz/mailman/listinfo/cryptoapi
List archive: http://lists.logix.cz/pipermail/cryptoapi
crypto/Kconfig +14 -0
@@ -9,6 +9,20 @@ help This option provides the core Cryptographic API. +config CRYPTO_RANDOM_FORTUNA + bool "The Fortuna CSRNG" + depends on CRYPTO && EXPERIMENTAL + select CRYPTO_SHA256 + select CRYPTO_AES if !(CRYPTO && (X86 && !X86_64)) + select CRYPTO_AES_586 if CRYPTO && (X86 && !X86_64) + help + Replaces the legacy Linux RNG with one using the CryptoAPI + and Fortuna designed by Ferguson and Schneier. Entropy estimation, + and a throttled /dev/random remain. Improvements include faster + /dev/urandom output and event input mixing. Entropy estimation + can be removed by changing source code. + Note: Requires AES and SHA256 to be built-in. + config CRYPTO_HMAC bool "HMAC support" depends on CRYPTO
drivers/char/random-fortuna.c +2121 -0
2,121 lines not on this page · raw message
drivers/char/Makefile +7 -1
@@ -7,7 +7,13 @@ # FONTMAPFILE = cp437.uni -obj-y += mem.o random.o tty_io.o n_tty.o tty_ioctl.o +obj-y += mem.o +ifeq ($(CONFIG_CRYPTO_RANDOM_FORTUNA),y) + obj-y += random-fortuna.o +else + obj-y += random.o +endif +obj-y += tty_io.o n_tty.o tty_ioctl.o obj-$(CONFIG_LEGACY_PTYS) += pty.o obj-$(CONFIG_UNIX98_PTYS) += pty.o
include/linux/sysctl.h +3 -1
@@ -202,7 +202,9 @@RANDOM_READ_THRESH =3 ,RANDOM_WRITE_THRESH =4 ,RANDOM_BOOT_ID =5 , - RANDOM_UUID=6 +RANDOM_UUID =6 , +RANDOM_DIGEST_ALGO =7 , + RANDOM_CIPHER_ALGO=8 };/* /proc/sys/kernel/pty */
PATCH 1/1 API for true Random Number Generators to add entropy
In reply to Andrew MortonHi all,
Here is a revised patch for 2.6.12-rc1 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);
so that true random number generator device drivers can add a entropy to the system.
Cheers,
Davidm
drivers/char/random.c +30 -0
@@ -1148,6 +1148,36 @@EXPORT_SYMBOL (generate_random_uuid);/******************************************************************** +* provide a mechanism for HW to add entropy that is of +* very good quality from a true random number generator +***************************************************************/ + +void add_true_randomness (__u32 *buf,int nwords) +{ +struct entropy_store *r; +int wakeup_check =0 ; + +/* +* if we have too much entropy, put some in the secondary pool +*/ + r = &blocking_pool; +if (r->entropy_count >= r->poolinfo->POOLBITS) + r = &nonblocking_pool; +else + wakeup_check = (r->entropy_count < random_read_wakeup_thresh); + +add_entropy_words (r, buf, nwords); +credit_entropy_store (r, nwords *32 ); + +/* +* wakeup if we added enough entropy to cross the threshold +*/ +if (wakeup_check && r->entropy_count >= random_read_wakeup_thresh) +wake_up_interruptible (&random_read_wait); +} +EXPORT_SYMBOL (add_true_randomness); + +/******************************************************************** * * Sysctl interface *
include/linux/random.h +2 -0
@@ -48,6 +48,8 @@ unsigned int value);extern void add_interrupt_randomness (int irq); +extern void add_true_randomness (__u32 *buf,int nwords); +extern void get_random_bytes (void *buf,int nbytes);void generate_random_uuid (unsigned char uuid_out[16 ]);
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Andrew MortonJivin Andrew Morton lays it down ...
Quoted 8 lines
Quoted 4 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Sorry about that, I had actually checked a fairly recent bk version and noticed quite a few changes. I used that to figure out what I could do that would apply reasonably to both 2.4 and 2.6 kernels, and then forgot about all those new changes and used the older release kernel.
See the new patch.
Quoted 1 line
Are we likely to see any in-kernel users of this?
Both the OCF port that I am working on and Evgeniy Polyakov's acrypto support devices that could use such an API. The OCF port has already has two drivers (hifn and safenet) that are using this and, depending on how this pans out, there will be another for Xscale soon.
Whether or not these users of it end up in the kernel is out of my hands somewhat :-)
Cheers,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Andrew MortonQuoted 10 lines · Andrew Morton
Quoted 4 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Are we likely to see any in-kernel users of this?
I added similar support to the pre hw_random AMD8111 driver a long time ago. Basically a timer that regularly read some dat from the hw random generator and feed it into the random code.
I think it is a good idea, because it doesnt make much sense imho to run a daemon for something that can be done in 20 lines of code in the kernel.
-Andi
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 15 lines · Andi Kleen
Quoted 10 lines · Andrew Morton
Quoted 3 lines · David McCullough
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);It neither applies correctly nor compiles in current kernels. 2.6.11 is very old in kernel time.
Are we likely to see any in-kernel users of this?
Quoted 8 lines
I added similar support to the pre
hw_randomAMD8111 driver a long time ago. Basically a timer that regularly read some dat from the hw random generator and feed it into the random code.I think it is a good idea, because it doesnt make much sense imho to run a daemon for something that can be done in 20 lines of code in the kernel.
Check your kernel history.
We -used- to need data from RNG directly into the kernel randomness pool. The consensus was that the FIPS testing should be moved to userspace.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 1 line
We -used- to need data from RNG directly into the kernel randomness
Are you sure? I dont think there was ever code to do this in mainline. There might have been something in -ac*, but not mainline.
Quoted 1 line
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways?
I think you just need to trust the random generator, it is like you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @)
I think it is a trade off between easy to use and saving of resources and overly paranoia. With an user space solution which near nobody uses currently (I am not aware of any distribution that runs that daemon)
it means most people wont have hardware supported randomness in their ssh, and I think that is a big drawback.
Also I dont like the memory consumption of the daemon. It needs at least 20+k for kernel stack, page tables etc. I know
a lot of people dont care about memory usage anymore, but I still do. It is not a lot of memory, but bloat does usually not come in big pieces but in small amounts of a time. And the code to do it from kernel space is really simple.
And it would suddenly make a lot of peoples ssh/https etc. more secure, which is a good thing. Probably would help Linux security a lot more than all these crazy - "ABI, what ABI?" - buffer overflow workarounds.
If you are really paranoid you can always turn off the sysctl and do it from userspace.
-Andi
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines
Quoted 1 line
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways? I think you just need to trust the random generator, it is like you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @)
For joe-user imho it's better to do a check from a cronjob once a day. But for high demand security, maybe make it pluggable? Like that a user can plug-in some module which does the testing? Then you can have several kinds of tests depending on your needs.
Folkert van Heusden
Auto te koop! Zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+------------------------------------------------------------------+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See | |http://vanheusden.com/multitail/features.html for a feature list. | +------------------------------------------= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 10 lines · On Sun, Mar 27, 2005 at 08:55:03PM +0200, [email protected] wrote:
Quoted 5 lines
Quoted 1 line
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways? I think you just need to trust the random generator, it is like you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @)
For joe-user imho it's better to do a check from a cronjob once a day. But for high demand security, maybe make it pluggable? Like that a user can plug-in some module which does the testing? Then you can have several kinds of tests depending on your needs.
In my old 2.4 patch there was a sysctl to turn off the kernel reseeding. If you turn it off you can do it in user space. That might be an option for the clinical paranoid.
BTW what do you do when the FIPS test fails? I dont see a good fallback path for this case.
-Andi
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 9 lines
Quoted 4 lines
For joe-user imho it's better to do a check from a cronjob once a day. But for high demand security, maybe make it pluggable? Like that a user can plug-in some module which does the testing? Then you can have several kinds of tests depending on your needs.
In my old 2.4 patch there was a sysctl to turn off the kernel reseeding. If you turn it off you can do it in user space. That might be an option for the clinical paranoid.
BTW what do you do when the FIPS test fails? I dont see a good fallback path for this case.
Send a message to klogd and let read() block untill the test no longer fails.
Folkert van Heusden
Auto te koop! Zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+------------------------------------------------------------------+ |UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)| |a try, it brings monitoring logfiles to a different level! See | |http://vanheusden.com/multitail/features.html for a feature list. | +------------------------------------------= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Andi KleenQuoted 2 lines · Andi Kleen
BTW what do you do when the FIPS test fails? I dont see a good fallback path for this case.
If the FIPS test fails, do the obvious: don't feed that data to the kernel (and credit entropy), and possibly stop using the hardware RNG under a human has intervened.
This is not rocket science. The fallback path is "use software", which is what most users do right now anyway.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 6 lines · Jeff Garzik
Quoted 2 lines · Andi Kleen
BTW what do you do when the FIPS test fails? I dont see a good fallback path for this case.
If the FIPS test fails, do the obvious: don't feed that data to the kernel (and credit entropy), and possibly stop using the hardware RNG
This will just cause hangs; basically it is a DOS.
Quoted 4 lines
under a human has intervened.
This is not rocket science. The fallback path is "use software", which is what most users do right now anyway.
Just that use software does not work on a headless machine sitting in a rack with not much disk IO.
-Andi
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to [email protected]Quoted 8 lines · [email protected] wrote:
Quoted 5 lines
Quoted 1 line
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways?
I think you just need to trust the random generator, it is like
you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @)For joe-user imho it's better to do a check from a cronjob once a day. But for
That would not catch the hardware failures seen in the field, in the past.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 10 lines · Jeff Garzik
Quoted 9 lines · [email protected] wrote:
Quoted 7 lines
Quoted 2 lines
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways? I think you just need to trust the random generator, it is like you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @)
Quoted 4 lines
Quoted 2 lines
For joe-user imho it's better to do a check from a cronjob once a day. But for
That would not catch the hardware failures seen in the field, in the past.
I am sure that all hardware in the field has failed in the past at some point - but that still does not mean we dont trust hardware in Linux. There simply is no choice.
I think we have a case here of the perfect being the enemy of the good.
I just want a simple solution that works for near all users out of the box without needing resource eating and hard to configure daemons of dubious value.
You are extrapolating from extremly unlikely events and think it makes sense to handle them - which I think is wrong.
The cronjob once a day or once an hour setup should catch the hardware failures anyways, and for shorter time amounts the random buffer in the kernel can handle bad input.
-Andi (who should probably just resubmit the patch)
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Andi KleenQuoted 5 lines · Andi Kleen
Quoted 1 line
We -used- to need data from RNG directly into the kernel randomness
Are you sure? I dont think there was ever code to do this in mainline. There might have been something in -ac*, but not mainline.
Yes, I am positive. I wrote the code. Look at the old Intel RNG driver code, before it grew AMD and VIA support, and became hw_random.
Quoted 4 lines
Quoted 1 line
pool. The consensus was that the FIPS testing should be moved to userspace.
Consensus from whom? And who says the FIPS testing is useful anyways?
lkml. Read the archives.
Quoted 2 lines
I think you just need to trust the random generator, it is like
you need to trust any other piece of hardware in your machine. Or do you check regularly if you mov instruction still works? @)
Hardware RNGs -have- failed in the past. And if you are going to credit entropy to the data -- a very big deal -- it damn well better be random data. Otherwise failures cascade through the system.
Quoted 2 lines
I think it is a trade off between easy to use and saving of resources and overly paranoia. With an user space solution which near nobody uses currently (I am not aware of any distribution that runs that daemon)
Debian does.
It's under-use is mainly because nobody has an RNG.
Quoted 2 lines
it means most people wont have hardware supported randomness in their ssh, and I think that is a big drawback.
"big drawback" == 99% of users right now.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to David McCulloughQuoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support for hw_random.c It is very simple and support only upto 4 bytes request, of course it is
not interested for anyone, but it is only 2-minutes example:
drivers/char/hw_random.c 2005-03-24 14:48:30.470407432 +0300 renamed from drivers/char/hw_random.c.orig 2005-03-24 13:36:05.000000000 +0300 +116 -1
@@ -34,6 +34,10 @@ #include <linux/smp_lock.h> #include <linux/mm.h> #include <linux/delay.h> +#include <linux/acrypto.h> +#include <linux/crypto_def.h> +#include <linux/crypto_stat.h> +#include <linux/highmem.h> #ifdef __i386__ #include <asm/msr.h>
@@ -73,6 +77,8 @@ #endif #define RNG_MISCDEV_MINOR 183 /* official */ + +static DEFINE_SPINLOCK(rng_lock); static int rng_dev_open (struct inode *inode, struct file *filp); static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
@@ -482,7 +488,6 @@ static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size, loff_t * offp) { - static DEFINE_SPINLOCK(rng_lock); unsigned int have_data; u32 data = 0; ssize_t ret = 0;
@@ -526,7 +531,109 @@ return ret; } +#define CONFIG_ACRYPTO +#ifdef CONFIG_ACRYPTO +static struct crypto_device *hwr_cdev; +static struct crypto_capability hwr_caps[] = { + {CRYPTO_OP_RNG, 0, 0, 100}, +}; + +static void hwr_data_ready(struct crypto_device *dev) +{ + struct crypto_session *s, *n; + unsigned long flags; + u32 data = 0; + unsigned int have_data; + u8 *ptr, *optr; + + local_irq_save(flags); + if (spin_trylock(&dev->session_lock)) { + local_irq_restore(flags); + return; + } + + list_for_each_entry_safe(s, n, &dev->session_list, dev_queue_entry) { + if (!session_completed(s) && !session_is_processed(s)) { + start_process_session(s); + spin_lock(&rng_lock); + have_data = 0; + if (rng_ops->data_present()) { + data = rng_ops->data_read(); + have_data = rng_ops->n_bytes; + } + spin_unlock (&rng_lock); + + optr = ptr = kmap_atomic(s->data.sg_dst[0].page, KM_USER0) + s->data.sg_dst[0].offset; + while (s->data.sg_dst[0].length && have_data) { + *ptr++ = data & 0xff; + s->data.sg_dst[0].length--; + have_data--; + data >>= 8; + } + kunmap_atomic(optr, KM_USER0); + + if (s->data.sg_dst[0].length) + broke_session(s); /* Need proper work deferring, see async_provider.c as example. */ + + crypto_stat_complete_inc(s); + crypto_session_dequeue_route(s); + complete_session(s); + stop_process_session(s); + } + } + + spin_unlock(&dev->session_lock); + local_irq_restore(flags); +} + +static int hwr_acrypto_init(struct rng_operations *ops) +{ + int err; + + hwr_cdev = kmalloc(sizeof(*hwr_cdev), GFP_KERNEL); + if (!hwr_cdev) { + printk(KERN_ERR "Failed to allocate new crypto_device structure.\n"); + return -ENOMEM; + } + + memset(hwr_cdev, 0, sizeof(*hwr_cdev)); + + hwr_cdev->cap = hwr_caps; + hwr_cdev->cap_number = sizeof(hwr_caps)/sizeof(hwr_caps[0]); + hwr_cdev->priv = ops; + hwr_cdev->data_ready = &hwr_data_ready; + snprintf(hwr_cdev->name, sizeof(hwr_cdev->name), "%s", "hwr"); + + err = crypto_device_add(hwr_cdev); + if (err) { + kfree(hwr_cdev); + hwr_cdev = NULL; + return err; + } + + printk(KERN_INFO "%s acrypto support is turned on.\n", hwr_cdev->name); + + return err; +} + +static void hwr_acrypto_fini(void) +{ + crypto_device_remove(hwr_cdev); + printk(KERN_INFO "%s acrypto support is turned off.\n", hwr_cdev->name); + kfree(hwr_cdev); + hwr_cdev = NULL; +} +#else +static int hwr_acrypto_init(struct rng_operations *ops) +{ + return 0; +} + +static void hwr_acrypto_fini(void) +{ +} +#endif /* * rng_init_one - look for and attempt to init a single RNG
@@ -549,9 +656,15 @@ goto err_out_cleanup_hw; } + rc = hwr_acrypto_init(rng_ops); + if (rc) + goto err_out_misc_unregister; + DPRINTK ("EXIT, returning 0\n"); return 0; +err_out_misc_unregister: + misc_deregister(&rng_miscdev); err_out_cleanup_hw: rng_ops->cleanup(); err_out:
@@ -617,6 +730,8 @@ { DPRINTK ("ENTER\n"); + hwr_acrypto_fini(); + misc_deregister (&rng_miscdev); if (rng_ops->cleanup)
So, one may use crypto_session_alloc(gimme_real_randomness) and that is all
(either from userspace or kernelspace).
As far as I can see, OCF support is also very simple.
What I want to say, is that since OCF and acrypto already support all RNG cases, it is better to port existing drivers to them, but not the reverse.
That will allow to use both old hw_random.c driver and any new one(HIFN, VIA, safenet, any other) without breaking any interfaces from both userspace and kernelspace.
If one of the asynchronous crypto layers will be included, /dev/random implementation can be changed to support it.
Quoted 2 lines
Cheers,
Davidm
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 19 lines · Evgeniy Polyakov
Quoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.
Quoted 7 lines
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support forhw_random.cIt is very simple and support only upto 4 bytes request, of course it is not interested for anyone, but it is only 2-minutes example:
If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
If you want to use the hardware RNG directly, it's simple: just open /dev/hw_random.
Hardware RNG should not go kernel->kernel without adding FIPS tests and such.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 34 lines · Jeff Garzik
Quoted 19 lines · Evgeniy Polyakov
Quoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.Quoted 8 lines
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support forhw_random.cIt is very simple and support only upto 4 bytes request, of course it is
not interested for anyone, but it is only 2-minutes example:If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
Quoted 5 lines
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.
hw_random can not and will not support HIFN, freescale, ixp and great majority of the existing and future HW crypto devices. I mean that userspace daemon(or any other one) which want to contribute entropy
should use crypto framwork to obtain all it's data, but not different access methods for each separate driver.
Quoted 1 line
Jeff
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Evgeniy Polyakov
hw_randomcan not and will not support HIFN, freescale, ixp and great majority of the existing and future HW crypto devices. I mean that userspace daemon(or any other one) which want to contribute
entropy
should use crypto framwork to obtain all it's data, but not different
access methods for each separate driver.
I don't mean to imply that hw_random should be modified to support all hardware RNGs. Separate drivers are perfectly OK with me. I would even take patches that split up hw_random into an RNG registration interface, and AMD/Intel/VIA support modules.
The part I disagree with is direct kernel->kernel RNG usage, with no intervening checks.
This has all been discussed years ago, when the FIPS testing was in the kernel (and then removed, per consensus).
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikJivin Jeff Garzik lays it down ...
Quoted 34 lines
Quoted 19 lines · Evgeniy Polyakov
Quoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.Quoted 8 lines
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support forhw_random.cIt is very simple and support only upto 4 bytes request, of course it is
not interested for anyone, but it is only 2-minutes example:If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
Quoted 5 lines
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.
For reference, the RNG on the Safenet I am using this with is FIPS140 certified. I believe the HIFN part is also but I place the doc that says so.
Cheers,
Davidm
Signature · 2 lines
David McCullough, [email protected] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 38 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 37 lines
Quoted 19 lines · Evgeniy Polyakov
Quoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.Quoted 8 lines
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support forhw_random.cIt is very simple and support only upto 4 bytes request, of course it is
not interested for anyone, but it is only 2-minutes example:If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.
Quoted 6 lines
Quoted 2 lines
Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.For reference, the RNG on the Safenet I am using this with is FIPS140 certified. I believe the HIFN part is also but I place the doc that says so.
At least HIFN 795x is certified.
Idea to validate entropy data is good in general,
but it should be implemented in a way allowing external both in-kernel and userspace
processes to contribute data.
So for in-kernel use we need such a mechanism, and userspace gkernel daemon
should use it(as the latest "step") too.
Your changes are correct, ioctl(RNDADDENTROPY) could even use it instead of direct
add_entropy_words()/credit_entropy_store(), but without external entropy contributors
it will not be applied by maintainers.
Quoted 3 lines
Cheers,
Davidm
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 45 lines · Evgeniy Polyakov
Quoted 34 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 32 lines
Quoted 20 lines · Evgeniy Polyakov
Quoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.Quoted 7 lines
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support forhw_random.cIt is very simple and support only upto 4 bytes request, of course it is not interested for anyone, but it is only 2-minutes example:If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
Quoted 7 lines
Quoted 3 lines
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.For reference, the RNG on the Safenet I am using this with is FIPS140 certified. I believe the HIFN part is also but I place the doc that says so.
Quoted 8 lines
At least HIFN 795x is certified.
Idea to validate entropy data is good in general, but it should be implemented in a way allowing external both in-kernel and userspace
processes to contribute data.
So for in-kernel use we need such a mechanism, and userspace gkernel
daemon
should useit(as the latest "step")too.
See the earlier discussion, when data validation was -removed- from the original Intel RNG driver, and moved to userspace.
Quoted 5 lines
Your changes are correct, ioctl(RNDADDENTROPY) could even use it instead of direct
add_entropy_words()/credit_entropy_store(), but without external entropy contributors
it will not be applied by maintainers.
No changes are needed, as the system is currently functional without these changes.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 11 lines · Jeff Garzik
Quoted 7 lines
Idea to validate entropy data is good in general,
but it should be implemented in a way allowing external both in-kernel and userspace
processes to contribute data.
So for in-kernel use we need such a mechanism, and userspace gkernel daemon
should useit(as the latest "step")too.See the earlier discussion, when data validation was -removed- from the original Intel RNG driver, and moved to userspace.
I'm not arguing against userspace validation, but if data produced _is_ cryptographically strong, why revalidate it again?
I definitely prefer such mechanism to be implemented, and if you want, it
can be turned by default off, and can be turned on using new ioctl() over /dev/random.
Quoted 8 lines
Quoted 5 lines
Your changes are correct, ioctl(RNDADDENTROPY) could even use it instead of direct
add_entropy_words()/credit_entropy_store(), but without external entropy contributors
it will not be applied by maintainers.No changes are needed, as the system is currently functional without these changes.
And how HIFN driver can contribute entropy?
It needs to create /dev/hifn_random, and rngd should be patched too? And even using any existing crypto framework why add 2 kernel/user copying, if we _want_ fast RNG and _know_ that it is valid?
You may say, that hardware can be broken and thus produces wrong data, but if user want, it can turn it on or off.
What about new ioctl() that will enable/disable entropy contribution from kernelspace without validating it? I can create a patch on top of David's.
Quoted 2 lines
Jeff
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Evgeniy Polyakov
Quoted 1 line · Jeff Garzik
See the earlier discussion, when data validation was -removed- from the original Intel RNG driver, and moved to userspace.
I'm not arguing against userspace validation, but if data produced _is_ cryptographically strong, why revalidate it again?
You cannot prove this without validating the data in software.
Otherwise, you are not handling the hardware-fault case.
It is foolish to presume that hardware always works correctly. It is -very- foolish to presume this, in cryptography.
Quoted 1 line
And how HIFN driver can contribute entropy?
Use the current chrdev->rngd method.
Quoted 1 line
You may say, that hardware can be broken and thus produces wrong data, but if user want, it can turn it on or off.
The user cannot know the data is bad unless it is constantly being validated.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 3 lines · Jeff Garzik
Quoted 1 line
And how HIFN driver can contribute entropy?
Use the current
chrdev->rngdmethod.
Why HIFN must be chardev?
Quoted 5 lines
Quoted 2 lines
You may say, that hardware can be broken and thus produces wrong data, but if user want, it can turn it on or off.
The user cannot know the data is bad unless it is constantly being validated.
The user can not use HW crypto processors, since he does not know if HW is broken or not, and thus must validate each crypto operation, i.e. reencrypt data in SW.
Not the point.
Validation can be performed in other HW
(like Xilinx which routes HW requests to the real devices), or in driver (if it is not FIPS validation).
So I still insist on creating ability to contribute entropy directly, without userspace validation.
It will be turned off by default.
Quoted 1 line
Jeff
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 3 lines · Evgeniy Polyakov
So I still insist on creating ability to contribute entropy directly, without userspace validation.
It will be turned off by default.
If its disabled by default, then you and 2-3 other people will use this feature. Not enough justification for a kernel API at that point.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 7 lines · Jeff Garzik
Quoted 3 lines · Evgeniy Polyakov
So I still insist on creating ability to contribute entropy directly, without userspace validation.
It will be turned off by default.If its disabled by default, then you and 2-3 other people will use this feature. Not enough justification for a kernel API at that point.
It is only because there are only couple of HW crypto devices in the tree, with one crypto framework inclusion there will be at least redouble.
Let's return to this discussion after it.
Thank you.
Quoted 2 lines
Jeff
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · Jeff Garzik
If its disabled by default, then you and 2-3 other people will use this feature. Not enough justification for a kernel API at that point.
It is only because there are only couple of HW crypto devices in the tree, with one crypto framework inclusion there will be at least redouble.
You missed the point. This has nothing to do with the crypto API. Jeff is saying that if this is disabled by default, then only a few users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may fail which can lead to catastrophic consequences, there is no point for this API at all.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 10 lines · Herbert Xu
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · Jeff Garzik
If its disabled by default, then you and 2-3 other people will use this feature. Not enough justification for a kernel API at that point.
It is only because there are only couple of HW crypto devices in the tree, with one crypto framework inclusion there will be at least redouble.
Quoted 7 lines
You missed the point. This has nothing to do with the crypto API. Jeff is saying that if this is disabled by default, then only a few users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may fail which can lead to catastrophic consequences, there is no point for this API at all.
Currently implemented in-tree drivers(hw_random.c, do not have spec about
VIA) do not perform any kind of validation, drivers created for OCF/acrypto
have HW validated RNG.
Such hardware is used mostly in embedded world where SW crypto processing
is too expensive, so users of such HW likely want to trust to theirs hardware and likely will turn in on.
That would be even be a good idea to have two way of turning it on - kernel config option and ioctl() one - to allow embedded systems with too limited userspace not change it's applications.
Of course with big fat warning about possible dramatical consequences.
Quoted 1 line
Cheers,
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Evgeniy Polyakov
Such hardware is used mostly in embedded world where SW crypto processing
is too expensive, so users of such HW likely want to trust to theirs hardware and likely will turn in on.
That's fine. All you need for these embedded users is a user-space daemon that feeds data from the hardware directly into /dev/random. No matter how small your system is, I'm sure you can spare a few hundred bytes for such a thing.
In fact most of these systems will have some sort of a general-purpose daemon that sits around which can perform such a task.
System calls on Linux are fast enough that there is really no advantage in doing this in the kernel.
But if you're really desparate, write a kernel module that does this in a kernel thread.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 12 lines · Herbert Xu
Quoted 5 lines · Evgeniy Polyakov
Such hardware is used mostly in embedded world where SW crypto processing
is too expensive, so users of such HW likely want to trust to theirs hardware and likely will turn in on.That's fine. All you need for these embedded users is a user-space daemon that feeds data from the hardware directly into
/dev/random. No matter how small your system is, I'm sure you can spare a few hundred bytes for such a thing.
Quoted 8 lines
In fact most of these systems will have some sort of a general-purpose daemon that sits around which can perform such a task.
System calls on Linux are fast enough that there is really no advantage in doing this in the kernel.
But if you're really desparate, write a kernel module that does this in a kernel thread.
It is not only about userspace/kernelspace system calls and data copying,
but about whole revalidation process, which can and is quite expensive, due to system calls, copying and validating itself,
I even think that using userspace rng daemon is completely useless for crypto HW devices - it is faster to obtain entropy from interrupts, than revalidating it in that way.
And what about initial bootup? When system needs to create randoom IP/dhcp/any ids? What about small router?
There are too many cases where userspace validation is just making things worse.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Evgeniy Polyakov
It is not only about userspace/kernelspace system calls and data copying,
but about whole revalidation process, which can and is quite expensive, due to system calls, copying and validating itself,
What I meant is if you don't need the revalidation then don't do it. That's the advantage of having it in user-space, *you* get to decide, not us.
Quoted 2 lines
And what about initial bootup? When system needs to create randoom IP/dhcp/any ids? What about small router?
Let's not reinvent the wheel, this is exactly what initramfs is for.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 10 lines · Herbert Xu
Quoted 5 lines · Evgeniy Polyakov
It is not only about userspace/kernelspace system calls and data copying,
but about whole revalidation process, which can and is quite expensive, due to system calls, copying and validating itself,What I meant is if you don't need the revalidation then don't do it. That's the advantage of having it in user-space, *you* get to decide, not us.
One can not add entropy data directly to the pool from kernelspace now. But now noone may do it, since all presented data is not validated. So when there will be validated HW RNG they still need to pass it's data through userspace validation daemon
(which btw makes tens to hundreds operations per bit according to FIPS).
Quoted 4 lines
Quoted 2 lines
And what about initial bootup? When system needs to create randoom IP/dhcp/any ids? What about small router?
Let's not reinvent the wheel, this is exactly what initramfs is for.
It is not panacea and even not always working solution.
If user turn that feature on - he is on his own.
Noone will complain on Linux if NIC is broken and produces wrong checksum
and HW checksum offloading is enabled using ethtools.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 3 lines · Evgeniy Polyakov
Noone will complain on Linux if NIC is broken and produces wrong checksum
and HW checksum offloading is enabled using ethtools.
Actually, that is a problem and people have definitely complained about it in the past.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 8 lines · Jeff Garzik
Quoted 3 lines · Evgeniy Polyakov
Noone will complain on Linux if NIC is broken and produces wrong checksum
and HW checksum offloading is enabled using ethtools.Actually, that is a problem and people have definitely complained about it in the past.
And what they were recommended to do? :)
I believe not changing drivers and stack, but only disable it using ethtool.
And people of course should be able to turn kernlspace <-> kernelspace RNG dataflow off if they fill it is insecure.
Quoted 2 lines
Jeff
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Evgeniy PolyakovQuoted 4 lines · Evgeniy Polyakov
Noone will complain on Linux if NIC is broken and produces wrong checksum
and HW checksum offloading is enabled using ethtools.
This is completely different. The worst that can happen with checksum offloading is that the packet is dropped. That's something people deal with on a daily basis since the Internet as a whole does not guarantee the delivery of packets.
On the other hand, /dev/random is something that has always promised to deliver random numbers that are totally unpredictable. People out there *depend* on this.
If that assumption is violated the result could be catastrophic.
That's why it's OK to have hardware RNG spit out unverified numbers in /dev/hw_random, but it's absolutely unaccpetable for the same numbers to add entropy to /dev/random without verification.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 10 lines · Herbert Xu
Quoted 4 lines · Evgeniy Polyakov
Noone will complain on Linux if NIC is broken and produces wrong checksum
and HW checksum offloading is enabled using ethtools.This is completely different. The worst that can happen with checksum offloading is that the packet is dropped. That's something people deal with on a daily basis since the Internet as a whole does not guarantee the delivery of packets.
It will just completely stop network dataflow.
It is of course not as catastrophic as removing strong random numbers from system.
But nevertheless - write cahce in disks may corrupt data on power-down, but people do not turn it off, crypto HW can be broken and does not encrypt dataflow, but people want it, broken NIC can corrupt data with various sg/offload combinations, but it can be enabled.
It is a feature, that _may_ broke thing badly.
But if all is ok - it is extremly usefull.
And as I said there may be other [HW/driver] validating techniques, not only userspace daemon.
Quoted 9 lines
On the other hand,
/dev/randomis something that has always promised to deliver random numbers that are totally unpredictable. People out there *depend* on this.If that assumption is violated the result could be catastrophic.
That's why it's OK to have hardware RNG spit out unverified numbers in
/dev/hw_random, but it's absolutely unaccpetable for the same numbers to add entropy to/dev/randomwithout verification.
Userspace daemon can read data from /dev/random and validate it in background, if it fells it is broken - turn feature off.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 7 lines · Kim Phillips
I did some tests and found that the udelay(200) call in
hw_random.cis not good for extreme RNG consumption. Whether or not such extremes occur in real life, on the mpc8541,/dev/hwrandomis an order of magnitude slower than/dev/random, and two orders of magnitude slower than/dev/urandom. The hardware RNG is capable of exceeding software/dev/randomspeeds plus it would alleviate the core to do other, more useful things (that's being realistic).
Consider what an RNG does: spews garbage.
In practical applications, you -do not- want to dedicate the machine to spewing garbage. The vast majority of users would prefer to use their machines for real stuff. Thus, "extreme RNG consumption" is largely irrelevant to sane usage.
That said, I cannot remember if the udelay() is hardcoding a policy decision (bad), or required for the hardware.
In any case, it is the wrong solution to simply "turn on the tap" and let the RNG spew data. There needs to be a limiting factor... typically rngd should figure out when /dev/random needs more entropy, or simply delay a little bit between entropy collection/stuffing runs.
Jeff
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Jeff Garzik
In any case, it is the wrong solution to simply "turn on the tap" and let the RNG spew data. There needs to be a limiting factor... typically rngd should figure out when
/dev/randomneeds more entropy, or simply delay a little bit between entropy collection/stuffing runs.
Completely agreed. Having it in rngd also allows the scheduler to do its job.
When applications need entropy from /dev/random and they can't get it, they'll simply block which allows rngd to run to refill the tank.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 9 lines · On Sat, 26 Mar 2005 10:47:45 +1100 Herbert Xu <[email protected]>…
Quoted 5 lines · Jeff Garzik
In any case, it is the wrong solution to simply "turn on the tap" and let the RNG spew data. There needs to be a limiting factor... typically rngd should figure out when
/dev/randomneeds more entropy, or simply delay a little bit between entropy collection/stuffing runs.Completely agreed. Having it in rngd also allows the scheduler to do its job.
It looks like we all misunderstand each other - why do you think that if there will be kernel <-> kernel RNG dataflow, then system will continuously spent all it's time to produce that data?
_Ability_ existence does not mean that only it must be used. Userspace daemon should be able to turn it on or off, but it is too expensive to allow it to be not only dataflow controller, but the only random numbers dataflow initiator.
I can create following patch on top of rngd - it will read from /dev/random, if read succeds too fast (or even better just to check pool counts), then rngd will turn HW RNG assist off and examine received data to check if it is valid.
Later it can be turned on again.
Quoted 2 lines
When applications need entropy from
/dev/randomand they can't get it, they'll simply block which allows rngd to run to refill the tank.
Such a blocking will be definitely a sign to turn HW RNG assist on.
Quoted 5 lines
Signature · 4 lines
Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Evgeniy Polyakov
It looks like we all misunderstand each other - why do you think that if there will be kernel <-> kernel RNG dataflow, then system will continuously spent all it's time to produce that data?
It doesn't matter whether it's like that or not.
The point is if you do it in the kernel then either you'll have very coarse controls over the rate of data coming out of the hardware RNG, e.g., only on/off, or you'll have to put more code in to set the rate appropriately.
Either way it's a loss compared to doing it in user-space.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 7 lines · On Sat, 26 Mar 2005 11:36:02 +1100 Herbert Xu <[email protected]>…
Quoted 5 lines · Evgeniy Polyakov
It looks like we all misunderstand each other - why do you think that if there will be kernel <-> kernel RNG dataflow, then system will continuously spent all it's time to produce that data?
Quoted 6 lines
It doesn't matter whether it's like that or not.
The point is if you do it in the kernel then either you'll have very coarse controls over the rate of data coming out of the hardware RNG, e.g., only on/off, or you'll have to put more code in to set the rate appropriately.
It is not the problem absolutely - just sleep if pool is full. It will limit usage but this is better than nothing.
Quoted 8 lines
Either way it's a loss compared to doing it in user-space.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[email protected]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikQuoted 7 lines · Jeff Garzik
Consider what an RNG does: spews garbage.
In practical applications, you -do not- want to dedicate the machine to spewing garbage. The vast majority of users would prefer to use their machines for real stuff. Thus, "extreme RNG consumption" is largely irrelevant to sane usage.
I have clients who run online Casinos. So spewing lots of reliable garbage is a good thing. That's why they chose Fortuna. Bad random data input is not a factor as long as there is enough trustwothy random data coming in.
JLC
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 4 lines · Jean-Luc Cooke
I have clients who run online Casinos. So spewing lots of reliable garbage is a good thing. That's why they chose Fortuna. Bad random data input is not a factor as long as there is enough trustwothy random data coming in.
I don't think the Casino operators will be very happy when their supposed hardware RNGs degenerate into software RNGs because it's feeding all zeros into /dev/random and nobody noticed...
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Herbert XuHi!
Quoted 11 lines · Herbert Xu
Quoted 4 lines · Evgeniy Polyakov
Noone will complain on Linux if NIC is broken and produces wrong checksum
and HW checksum offloading is enabled using ethtools.This is completely different. The worst that can happen with checksum offloading is that the packet is dropped. That's something people deal with on a daily basis since the Internet as a whole does not guarantee the delivery of packets.
Quoted 5 lines
On the other hand,
/dev/randomis something that has always promised to deliver random numbers that are totally unpredictable. People out there *depend* on this.If that assumption is violated the result could be catastrophic.
Yes, and we had huge security hole where it sometimes gave same random data to two different processes on smp, and noone noticed for 10 years.... /dev/random is not as critical as you paint it.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Herbert XuQuoted 10 lines · Herbert Xu
Quoted 8 lines · Evgeniy Polyakov
Quoted 2 lines · Jeff Garzik
If its disabled by default, then you and 2-3 other people will use this feature. Not enough justification for a kernel API at that point.
It is only because there are only couple of HW crypto devices in the tree, with one crypto framework inclusion there will be at least redouble.
Quoted 7 lines
You missed the point. This has nothing to do with the crypto API. Jeff is saying that if this is disabled by default, then only a few users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may fail which can lead to catastrophic consequences, there is no point for this API at all.
What catastrophic consequences? Noone is likely to even *notice*, and it does not help practical attack at all. Unless hardware RNGs are *very* flakey (like, more flakey than harddrives), this is not a problem.
I can assure you that failing hdd will have more catastrophic consequences.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 4 lines · Pavel Machek
What catastrophic consequences? Noone is likely to even *notice*, and it does not help practical attack at all. Unless hardware RNGs are *very* flakey (like, more flakey than harddrives), this is not a problem.
The reason some people use hardware RNGs in the first place is because they don't trust the software RNGs. When the hardware RNG fails but continues to send data to /dev/random, /dev/random essentially degenerates into a software RNG. Now granted /dev/random is a pretty good software RNG, however, for some purposes it just isn't good enough.
Otherwise we can just do away with it and always use /dev/urandom.
Someone else raised the example of Casinos using hardware RNGs. Some of them are doing this to comply with government regulation. In that case, using data from the software RNG when the hardware has failed would be violating the law.
Quoted 2 lines
I can assure you that failing hdd will have more catastrophic consequences.
That's we have things like RAID and backups.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Hi!
Quoted 9 lines
Quoted 3 lines
What catastrophic consequences? Noone is likely to even *notice*, and it does not help practical attack at all. Unless hardware RNGs are *very* flakey (like, more flakey than harddrives), this is not a problem.
The reason some people use hardware RNGs in the first place is because they don't trust the software RNGs. When the hardware RNG fails but continues to send data to
/dev/random,/dev/randomessentially degenerates into a software RNG. Now granted/dev/randomis a pretty good software RNG, however, for some purposes it just isn't good enough.
It seems to me that people wanting this level of assurance should do their own FIPS (or whatever) tests.
Interrupts are not totally unpredictable, either, yet noone runs FIPS tests on them. I'd say that hardware generator is still better than interrupt timing. If someone really wants casino-level of randomness, they should do it all in userspace, probably off interrupt entropy sources, and do their own FIPS testing.
Quoted 6 lines
Otherwise we can just do away with it and always use
/dev/urandom.Someone else raised the example of Casinos using hardware RNGs. Some of them are doing this to comply with government regulation. In that case, using data from the software RNG when the hardware has failed would be violating the law.
Well, you are still using hardware RNG, but failed one. I do not see how you can break law with that... given that hardware RNG had proper certification in the first place.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 3 lines · Pavel Machek
It seems to me that people wanting this level of assurance should do their own FIPS (or whatever) tests.
That's exactly what the current scheme of driver + rngd allows you to do. For those that require high assurance, they can let rngd do the checks. Otherwise they can disable the checks and just let rngd feed data from /dev/hw_random into /dev/random.
It's not just about the quality checks. It's also about deciding the rate at which data should be fed into /dev/random.
Feeding too much means that you might be wasting system resources (CPU/PCI bus/etc.). Feeding too little means that /dev/random users may block unnecessarily.
Doing the feeding in a process means that you can feed exactly the right amount. You feed only when the /dev/random's pool is depleted and you feed exactly the amount of data that is needed to replenish the pool.
Quoted 1 line
Interrupts are not totally unpredictable, either, yet noone runs FIPS
I haven't looked at this but if that's the case we might want to look at lowering the entropy count for that.
Quoted 8 lines
Quoted 4 lines
Someone else raised the example of Casinos using hardware RNGs. Some of them are doing this to comply with government regulation. In that case, using data from the software RNG when the hardware has failed would be violating the law.
Well, you are still using hardware RNG, but failed one. I do not see how you can break law with that... given that hardware RNG had proper certification in the first place.
Actually in the scheme proposed in this thread the hardware RNG could be feeding a stream of zeros into /dev/random which means that the /dev/random user will be using a software RNG.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Herbert XuQuoted 11 lines · Herbert Xu
Quoted 4 lines · Pavel Machek
What catastrophic consequences? Noone is likely to even *notice*, and it does not help practical attack at all. Unless hardware RNGs are *very* flakey (like, more flakey than harddrives), this is not a problem.
The reason some people use hardware RNGs in the first place is because they don't trust the software RNGs. When the hardware RNG fails but continues to send data to
/dev/random,/dev/randomessentially degenerates into a software RNG. Now granted/dev/randomis a pretty good software RNG, however, for some purposes it just isn't good enough.
I think the most people use hardware accelerated devices to speed up theirs calculations - embedded world is the best example - applications that are written to use /dev/random
will work just too slow, so hardware vendors
place HW assistant chips to unload that very cpu-intencive work from main CPU.
Without ability speed this up in kernel, we completely [ok, almost] loose all RNG advantages.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 3 lines · Evgeniy Polyakov
Without ability speed this up in kernel, we completely [ok, almost] loose all RNG advantages.
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 8 lines · Herbert Xu
Quoted 3 lines · Evgeniy Polyakov
Without ability speed this up in kernel, we completely [ok, almost] loose all RNG advantages.
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
Quote from VIA RNG crypto analysis:
"Bitrate. The RNG generates output at significantly higher rates than most PC-based randomness resources. Raw bits are produced at rates of 30 to 50 Mbits/sec, and whitened bits were observed at rates of 4 to 9 Mbits/sec. Variations in output rates depend on the RNG configuration and the oscillator rates. PRNGs seeded with the Nehemiah RNG should be able to easily sustain output in excess of 2 Mbits of entropy per second, which should eliminate blocked PRNG reads in virtually all applications."
While raw bits reading from hw_random on the fastest VIA boards can exceed 55mbits per second [above quite was taken from VIA C3 Nehemiah analysis], it is not evaluated in rngd and is not written back to the /dev/random.
David provided his patch exactly because of "Adding this can dramatically improve the performance of /dev/random on small embedded systems which do not generate much entropy."
and it works.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 11 lines · Evgeniy Polyakov
Quoted 3 lines · Herbert Xu
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
While raw bits reading from
hw_randomon the fastest VIA boards can exceed 55mbits per second [above quite was taken from VIA C3 Nehemiah analysis], it is not evaluated in rngd and is not written back to the/dev/random.
Well when you get 55mb/s from /dev/random please get back to me.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 7 lines · Herbert Xu
Quoted 6 lines · Evgeniy Polyakov
Quoted 3 lines · Herbert Xu
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
Quoted 7 lines
Quoted 5 lines
While raw bits reading from
hw_randomon the fastest VIA boards can exceed 55mbits per second [above quite was taken from VIA C3 Nehemiah analysis], it is not evaluated in rngd and is not written back to the/dev/random.Well when you get 55mb/s from
/dev/randomplease get back to me.
I cant, noone writes 55mbit into it, but HW RNG drivers could. :)
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Hi!
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 3 lines
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
While raw bits reading from
hw_randomon the fastest VIA boards can exceed 55mbits per second [above quite was taken from VIA C3 Nehemiah analysis], it is not evaluated in rngd and is not written back to the/dev/random.
Quoted 3 lines
Quoted 1 line
Well when you get 55mb/s from
/dev/randomplease get back to me.I cant, noone writes 55mbit into it, but HW RNG drivers could. :)
Exactly, on via machines, it might be good idea to hook /dev/random directly to hardware random generator... that should give you 55mbit/sec.
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Evgeniy PolyakovQuoted 9 lines · Evgeniy Polyakov
Quoted 7 lines
Quoted 5 lines · Herbert Xu
Quoted 4 lines
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
Well when you get 55mb/s from
/dev/randomplease get back to me.I cant, noone writes 55mbit into it, but HW RNG drivers could. :)
Are you intending to feed that into /dev/random at 55mb/s?
If not then how is this an argument against doing it in userspace through rngd?
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 7 lines · Herbert Xu
Quoted 6 lines · Evgeniy Polyakov
Quoted 5 lines
Quoted 5 lines · Herbert Xu
Quoted 4 lines
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Well when you get 55mb/s from
/dev/randomplease get back to me.I cant, noone writes 55mbit into it, but HW RNG drivers could. :)
Are you intending to feed that into
/dev/randomat 55mb/s?If not then how is this an argument against doing it in userspace through rngd?
Yes.
Untill pool is filled and then sleep there.
When someone wants to draw from the pool - awake and fill it again.
I clearly see your point here and I agree that it must be default method for entropy producing, but if there are possibility to speed that up, such techniques should be allowed to be used.
It is really faster to fill pool from the kernelspace without copying/validating it in userspace.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 14 lines · Evgeniy Polyakov
Quoted 13 lines · Herbert Xu
Quoted 9 lines · Evgeniy Polyakov
Quoted 7 lines
Quoted 5 lines · Herbert Xu
Quoted 4 lines
Well if you can demonstrate that you're getting a higher rate of throughput from your RNG by doing this in kernel space vs. doing it in user space please let me know.
Well when you get 55mb/s from
/dev/randomplease get back to me.I cant, noone writes 55mbit into it, but HW RNG drivers could. :)
Are you intending to feed that into
/dev/randomat 55mb/s?
Quoted 8 lines
Quoted 2 lines
If not then how is this an argument against doing it in userspace through rngd?
Yes.
Untill pool is filled and then sleep there.
When someone wants to draw from the pool - awake and fill it again.I clearly see your point here and I agree that it must be
I mean userspace validating and load balancing must be default method for entropy producing.
Quoted 7 lines
default method for entropy producing, but if there are possibility to speed that up, such techniques should be allowed to be used.
It is really faster to fill pool from the kernelspace without copying/validating it in userspace.
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Herbert XuQuoted 1 line · Herbert Xu
Well when you get 55mb/s from
/dev/randomplease get back to me.
I will add you to my list for notification of Fortuna Patch to /dev/random (/dev/urandom)
JLC
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Evgeniy PolyakovQuoted 8 lines · Evgeniy Polyakov
I think the most people use hardware accelerated devices to speed up theirs calculations - embedded world is the best example - applications that are written to use
/dev/random
will work just too slow, so hardware vendors
place HW assistant chips to unload that very cpu-intencive work from main CPU.
Without ability speed this up in kernel, we completely [ok, almost] loose all RNG advantages.
The reason for hardware random number generators is that computers are pretty deterministic machines and random number sources tend to be few, far between, very low bitrate, and of uncertain randomness. So much so that without a user (a decent entropy source), a computer might take minutes to collect a few hundred bits of entropy.[1] The advantage of a hardware RNG is that it is random in the first place, high bitrates are just icing on the cake.
[1] Vague recollection from a hardware RNG article.
The thing is few applications need truly random data, and even fewer need much. (Maybe casinos). Even cryptographic applications don't need much; they can be served by a carefully crafted pseudo-random number generator, so long as that generator is seeded with enough entropy. (512 bits of entropy is plenty). And while a crypographically strong pseudo-random number generator is pretty cpu-intensive, I would be quite surprised to learn that a hardware RNG is faster.
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Herbert XuQuoted 7 lines · Herbert Xu
You missed the point. This has nothing to do with the crypto API. Jeff is saying that if this is disabled by default, then only a few users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may fail which can lead to catastrophic consequences, there is no point for this API at all.
Wait a minute, if it fails the system drops back to software, which is not as good in a pedantic analysis, but perhaps falls a good bit short of "catastrophic consequences" as most people would characterize that phrase. And more to the point, now that many CPUs and chipsets are the RNG of choice, what is the actual probability of a failure of the RNG leaving a functional system (that's a real question seeking response from someone who has some actual data).
It would be desirable for the kernel to detect a failure and do something appropriate, but I have to feel that if an RNG is in the CPU or chipset, it would serve users better to use it. By default. People who need quality entropy would be better served by a hardware source, and people who don't (or fail to realize they do) would not be hurt by use of better numbers.
I'm not sure you would get people to agree what should be done if a hardware RNG fails, other than make the failure information available to user space.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 1 line · Bill Davidsen
Wait a minute, if it fails the system drops back to software,
Does it? It would seem that if it fails and begins returning all zeroes, then the seed function would (depending on the implementation) be called like this:
add_random_bytes("\0\0\0\0".... , 4096);
add_random_bytes("\0\0\0\0".... , 4096);
[...]
Or:
add_random_bytes("\0\0\0\0".... , 4096);add_random_bytes(soft_random() , 64);
add_random_bytes("\0\0\0\0".... , 4096);add_random_bytes(soft_random() , 64);
[...]
In either case, it's very bad, and will likely return cause some _very_ predictable data to be emitted.
Quoted 3 lines
I'm not sure you would get people to agree what should be done if a hardware RNG fails, other than make the failure information available to user space.
How do you know if it fails? You know when your disk fails and begins giving bad data because the filesystem detects that the data is invalid, but how do you tell when your random number generator starts giving bad data? AFAIK, the only way to do that is to continuously monitor the random data produced and _immediately_ stop the data flow when you start getting bad data. That should only be done from a userspace rngd-type daemon.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-) ------END GEEK CODE BLOCK------
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Bill DavidsenQuoted 6 lines · Bill Davidsen
Quoted 4 lines · Herbert Xu
You missed the point. This has nothing to do with the crypto API. Jeff is saying that if this is disabled by default, then only a few users will enable it and therefore use this API.
Quoted 6 lines
Quoted 3 lines
Since we can't afford to enable it by default as hardware RNG may fail which can lead to catastrophic consequences, there is no point for this API at all.
Wait a minute, if it fails the system drops back to software, which is not as good in a pedantic analysis, but perhaps falls a good bit short of "catastrophic consequences" as most people would characterize that phrase. And more to the point, now that many CPUs and chipsets are the RNG of choice, what is the actual probability of a failure of the RNG leaving a functional system (that's a real question seeking response from someone who has some actual data).
As I've said, in the past the Intel RNGs in particular -have- failed, but the rest of the system keeps on working just fine.
It probably depends on the hardware implementation; I think the Intel RNG was based on a thermal diode, or somesuch.
In the cases where an RNG has failed in the past, the system has worked as expected: rngd stopped feeding data into the entropy pool.
If the VIA RNG (on-CPU) fails, that's probably indicative of a larger problem, though.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 14 lines · Jeff Garzik
Quoted 12 lines · Bill Davidsen
Quoted 7 lines · Herbert Xu
You missed the point. This has nothing to do with the crypto API. Jeff is saying that if this is disabled by default, then only a few users will enable it and therefore use this API.
Since we can't afford to enable it by default as hardware RNG may fail which can lead to catastrophic consequences, there is no point for this API at all.
Quoted 4 lines
Quoted 1 line
Wait a minute, if it fails the system drops back to software, which is not as good in a pedantic analysis, but perhaps falls a good bit short of "catastrophic consequences" as most people would characterize that phrase. And more to the point, now that many CPUs and chipsets are the RNG of choice, what is the actual probability of a failure of the RNG leaving a functional system (that's a real question seeking response from someone who has some actual data).
As I've said, in the past the Intel RNGs in particular -have- failed, but the rest of the system keeps on working just fine.
People have been hit by meteors, too. I wasn't questioning that it was possible in practice, or even that it did happen, but trying to get some quantitative values for failure rates. I guess that wasn't clear, I know entropy is scarse on embedded systems, I don't know what the magnitude of the RNG failure is, so I'm coming from the "router in a cigar box" point of view.
Quoted 4 lines
It probably depends on the hardware implementation; I think the Intel RNG was based on a thermal diode, or somesuch.
In the cases where an RNG has failed in the past, the system has worked as expected: rngd stopped feeding data into the entropy pool.
If the hardware RNG always fails to all zeros it should be possible to detect that it failed with the need for userspace daemons. While true random bits might legitimately have 10k zeros in a row, I will bet that if it happens the device isn't working.
I'm assuming that the hardware RNG is only read when a read on /dev/random occurs and there isn't enough entropy available to satisfy the read. I realize that may not be true, I just haven't had time to go study the code.
Quoted 2 lines
If the VIA RNG (on-CPU) fails, that's probably indicative of a larger problem, though.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 1 line · Bill Davidsen
If the hardware RNG always fails to all zeros it should be possible to detect that it failed with the need for userspace daemons. While true random bits might legitimately have 10k zeros in a row, I will bet that if it happens the device isn't working.
Or all 1's (more likely), or all 0x55's, or...
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 1 line · Jeff
Or all 1's (more likely), or all 0x55's, or...
Stray thought - to follow up stray thought:
Hmmm ... run some numbers through a good compression program, and complain if they compress much.
Signature · 3 lines
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[email protected]> 1.650.933.1373, 1.925.600.0401Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikHi!
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
See the earlier discussion, when data validation was -removed- from the original Intel RNG driver, and moved to userspace.
I'm not arguing against userspace validation, but if data produced _is_ cryptographically strong, why revalidate it again?
Quoted 6 lines
You cannot prove this without validating the data in software.
Otherwise, you are not handling the hardware-fault case.
It is foolish to presume that hardware always works correctly. It is -very- foolish to presume this, in cryptography.
We trust hardware, anyway. Like your disk *could* accidentaly turn on setuid bit on /bin/bash, and we do not insist on userspace disk-validator.
I do not think paranoia about random generators is neccessary. If vendor provides you with random generator, it should be ok to just use it. [Did anyone see failing hw random generator, *at all*?] I can provide you with plenty of failing hdds....
Pavel
Signature · 2 lines
People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 5 lines · Pavel Machek
I do not think paranoia about random generators is neccessary. If vendor provides you with random generator, it should be ok to just use it. [Did anyone see failing hw random generator, *at all*?] I can provide you with plenty of failing hdds....
We've been through this before. It's not a question of trusting the hardware to be /dev/hw_random, it's a question of trusting it to be /dev/random.
/dev/random is special in that we've gone to extraordinary lengths to make sure that it contains the amount of entropy that we say it does.
So while it'd be perfectly OK to feed unverified data through /dev/hw_random, the same cannot be done for /dev/random.
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Pavel MachekHello!
Quoted 3 lines
We trust hardware, anyway. Like your disk *could* accidentaly turn on setuid bit on
/bin/bash, and we do not insist on userspace disk-validator.
But there is a very important difference: the most likely (both in theory and practice) failure of a disk is clearly visible, while failures of HW RNG's are likely to be silent (the data are just less random than they should be).
Have a nice fortnight
Signature · 3 lines
Martin `MJ' Mares <[email protected]> http://atrey.karlin.mff.cuni.cz/~mj/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Top ten reasons to procrastinate: 1.
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to David McCulloughQuoted 34 lines · David McCullough
Jivin Jeff Garzik lays it down ...
Quoted 32 lines
Quoted 20 lines · Evgeniy Polyakov
Quoted 11 lines · David McCullough
Hi all,
Here is a small patch for 2.6.11 that adds a routine:
add_true_randomness(__u32 *buf, int nwords);so that true random number generator device drivers can add a entropy to the system. Drivers that use this can be found in the latest release of ocf-linux, an asynchronous crypto implementation for linux based on the *BSD Cryptographic Framework.
Quoted 4 lines
http://ocf-linux.sourceforge.net/
Adding this can dramatically improve the performance of
/dev/randomon small embedded systems which do not generate much entropy.Quoted 7 lines
People will not apply any kind of such changes.
Both OCF and acrypto already handle all RNG cases - no need for any kind of userspace daemon or entropy (re)injection mechanism. Anyone who want to use HW randomness may use OCF/acrypto mechanism. For example here is patch to enable acrypto support forhw_random.cIt is very simple and support only upto 4 bytes request, of course it is not interested for anyone, but it is only 2-minutes example:If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
Quoted 8 lines
Quoted 3 lines
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.For reference, the RNG on the Safenet I am using this with is FIPS140 certified. I believe the HIFN part is also but I place the doc that says so.
FIPS certification is not relevant to the discussion.
I am talking about active testing of -all data- that is produced by an RNG, before making use of it. Please read the source code of rngd.
Jeff
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jeff GarzikQuoted 10 lines · Jeff Garzik
If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.
If your RNG were properly written, it shouldn't matter if the data you're pumping into /dev/random passed muster or not. If you're tracking entropy count, then that's a different story of course.
I've been commissioned to write Fortuna RNG for Linux and weddings, houses and cars not withstanding, I should I it ready soon to be given to LKML for digestion.
JLC
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Quoted 4 lines · Jean-Luc Cooke
Quoted 2 lines · Jeff Garzik
If you want to add entropy to the kernel entropy pool from hardware RNG, you should use the userland daemon, which detects non-random (broken) hardware and provides throttling, so that RNG data collection does not consume 100% CPU.
Quoted 8 lines
Quoted 3 lines
If you want to use the hardware RNG directly, it's simple: just open
/dev/hw_random.Hardware RNG should not go
kernel->kernelwithout adding FIPS tests and such.If your RNG were properly written, it shouldn't matter if the data you're pumping into
/dev/randompassed muster or not. If you're tracking entropy count, then that's a different story of course.
It's rather lame to add data, without also crediting entropy.
Further, it wastes many CPU cycles in many places, if you are doing nothing but pumping bad data (all 1's, for example) into /dev/random.
Quoted 3 lines
I've been commissioned to write Fortuna RNG for Linux and weddings, houses and cars not withstanding, I should I it ready soon to be given to LKML for digestion.
Sounds great.
Jeff
Herbert Xu
maintainerRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Jean-Luc CookeQuoted 4 lines · Jean-Luc Cooke
If your RNG were properly written, it shouldn't matter if the data you're pumping into
/dev/randompassed muster or not. If you're tracking entropy count, then that's a different story of course.
We're talking about hardware RNGs here so we need to take hardware faults into account.
Cheers,
Signature · 4 lines
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txtRe: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
In reply to Evgeniy PolyakovQuoted 3 lines · Evgeniy Polyakov
For example here is patch to enable acrypto support for
hw_random.cIt is very simple and support only upto 4 bytes request, of course it is not interested for anyone, but it is only 2-minutes example:
Full port.
drivers/char/hw_random.c 2005-03-25 08:46:03.841601032 +0300 renamed from drivers/char/hw_random.c.orig 2005-03-24 13:36:05.000000000 +0300 +170 -1
@@ -34,6 +34,10 @@ #include <linux/smp_lock.h> #include <linux/mm.h> #include <linux/delay.h> +#include <linux/acrypto.h> +#include <linux/crypto_def.h> +#include <linux/crypto_stat.h> +#include <linux/highmem.h> #ifdef __i386__ #include <asm/msr.h>
@@ -73,6 +77,8 @@ #endif #define RNG_MISCDEV_MINOR 183 /* official */ + +static DEFINE_SPINLOCK(rng_lock); static int rng_dev_open (struct inode *inode, struct file *filp); static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size,
@@ -482,7 +488,6 @@ static ssize_t rng_dev_read (struct file *filp, char __user *buf, size_t size, loff_t * offp) { - static DEFINE_SPINLOCK(rng_lock); unsigned int have_data; u32 data = 0; ssize_t ret = 0;
@@ -526,7 +531,163 @@ return ret; } +#ifdef CONFIG_ACRYPTO +static struct crypto_device *hwr_cdev; +static struct crypto_capability hwr_caps[] = { + {CRYPTO_OP_RNG, 0, 0, 100}, +}; +static int hwr_pid, hwr_need_exit; +static struct completion hwr_thread_exited; +static DECLARE_WAIT_QUEUE_HEAD(hwr_wait); + + +static void hwr_data_ready(struct crypto_device *dev) +{ + wake_up(&hwr_wait); +} + +static int hwr_process(void *data) +{ + struct crypto_device *dev = data; + struct crypto_session *s, *n; + u32 rng_data = 0; + unsigned int have_data, size; + int i; + u8 *ptr; + + daemonize("%s", dev->name); + allow_signal(SIGTERM); + + while (!hwr_need_exit) { + interruptible_sleep_on_timeout(&hwr_wait, 10); + + list_for_each_entry_safe(s, n, &dev->session_list, dev_queue_entry) { + if (!session_completed(s) && !session_is_processed(s)) { + start_process_session(s); + + if (s->data.sg_src_num != s->data.sg_dst_num) { + dprintk("%s: session %llu [%llu]: different src/dst sg numbers: %d %d.\n", + dev->name, s->ci.id, s->ci.dev_id, + s->data.sg_src_num, s->data.sg_dst_num); + broke_session(s); + goto out_complete_session; + } + + for (i=0; i<s->data.sg_src_num; ++i) { + if (s->data.sg_dst[i].length != s->data.sg_src[i].length) { + dprintk("%s: session %llu [%llu]: sg %d different src/dst lengths: %u %u.\n", + dev->name, s->ci.id, s->ci.dev_id, i, + s->data.sg_src[i].length, s->data.sg_dst[i].length); + if (s->data.sg_dst[i].length) + s->data.sg_src[i].length = s->data.sg_dst[i].length; + else + s->data.sg_dst[i].length = s->data.sg_src[i].length; + + } + + size = s->data.sg_dst[i].length; + + while (size) { + spin_lock(&rng_lock); + have_data = 0; + if (rng_ops->data_present()) { + rng_data = rng_ops->data_read(); + have_data = rng_ops->n_bytes; + } + spin_unlock (&rng_lock); + + ptr = kmap_atomic(s->data.sg_dst[i].page, KM_USER0) + s->data.sg_dst[i].offset + + s->data.sg_dst[i].length - size; + + while (size && have_data) { + *ptr = rng_data & 0xff; + size--; + have_data--; + rng_data >>= 8; + } + kunmap_atomic(ptr, KM_USER0); + + if (size) + msleep_interruptible(1); + } + } + + crypto_stat_complete_inc(s); + +out_complete_session: + crypto_session_dequeue_route(s); + complete_session(s); + stop_process_session(s); + } + } + } + + complete_and_exit(&hwr_thread_exited, 0); +} + +static int hwr_acrypto_init(struct rng_operations *ops) +{ + int err; + + hwr_cdev = kmalloc(sizeof(*hwr_cdev), GFP_KERNEL); + if (!hwr_cdev) { + printk(KERN_ERR "Failed to allocate new crypto_device structure.\n"); + return -ENOMEM; + } + + memset(hwr_cdev, 0, sizeof(*hwr_cdev)); + + hwr_cdev->cap = hwr_caps; + hwr_cdev->cap_number = sizeof(hwr_caps)/sizeof(hwr_caps[0]); + hwr_cdev->priv = ops; + hwr_cdev->data_ready = &hwr_data_ready; + snprintf(hwr_cdev->name, sizeof(hwr_cdev->name), "%s", "hwr"); + + init_completion(&hwr_thread_exited); + hwr_pid = kernel_thread(hwr_process, hwr_cdev, CLONE_FS | CLONE_FILES); + if (hwr_pid < 0) { + err = hwr_pid; + goto err_out_free_cdev; + } + err = crypto_device_add(hwr_cdev); + if (err) + goto err_out_remove_thread; + + printk(KERN_INFO "%s acrypto support is turned on.\n", hwr_cdev->name); + +err_out_remove_thread: + hwr_need_exit = 1; + kill_proc(hwr_pid, SIGTERM, 0); + wait_for_completion(&hwr_thread_exited); +err_out_free_cdev: + kfree(hwr_cdev); + hwr_cdev = NULL; + return err; +} + +static void hwr_acrypto_fini(void) +{ + crypto_device_remove(hwr_cdev); + printk(KERN_INFO "%s acrypto support is turned off.\n", hwr_cdev->name); + + hwr_need_exit = 1; + kill_proc(hwr_pid, SIGTERM, 0); + wait_for_completion(&hwr_thread_exited); + + kfree(hwr_cdev); + hwr_cdev = NULL; +} +#else +static int hwr_acrypto_init(struct rng_operations *ops) +{ + return 0; +} + +static void hwr_acrypto_fini(void) +{ +} +#endif /* * rng_init_one - look for and attempt to init a single RNG
@@ -549,9 +710,15 @@ goto err_out_cleanup_hw; } + rc = hwr_acrypto_init(rng_ops); + if (rc) + goto err_out_misc_unregister; + DPRINTK ("EXIT, returning 0\n"); return 0; +err_out_misc_unregister: + misc_deregister(&rng_miscdev); err_out_cleanup_hw: rng_ops->cleanup(); err_out:
@@ -617,6 +784,8 @@ { DPRINTK ("ENTER\n"); + hwr_acrypto_fini(); + misc_deregister (&rng_miscdev); if (rng_ops->cleanup)
Signature · 3 lines
Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski