[PATCH 1/1] arm/crypto: Add optimized AES and SHA1 routines
Add assembler versions of AES and SHA1 for ARM platforms. This has provided up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1. Platform CPU SPeedEndian Before (bps) After (bps) Improvement IXP425 533 MHz big 1121704215566294~38% KS8695 166 MHz little3828549 5795373~51% Signed-off-by: David McCullough --- diff -Npur linux-3.5.orig/arch/arm/crypto/aes-armv4.S linux-3.5/arch/arm/crypto/aes-armv4.S --- linux-3.5.orig/arch/arm/crypto/aes-armv4.S 1970-01-01 10:00:00.0 +1000 +++ linux-3.5/arch/arm/crypto/aes-armv4.S 2012-08-07 11:11:31.671359005 +1000 @@ -0,0 +1,1112 @@ +#define __ARM_ARCH__ __LINUX_ARM_ARCH__ +@ +@ Written by Andy Polyakov for the OpenSSL +@ project. The module is, however, dual licensed under OpenSSL and +@ CRYPTOGAMS licenses depending on where you obtain it. For further +@ details see http://www.openssl.org/~appro/cryptogams/. +@ + +@ AES for ARMv4 + +@ January 2007. +@ +@ Code uses single 1K S-box and is >2 times faster than code generated +@ by gcc-3.4.1. This is thanks to unique feature of ARMv4 ISA, which +@ allows to merge logical or arithmetic operation with shift or rotate +@ in one instruction and emit combined result every cycle. The module +@ is endian-neutral. The performance is ~42 cycles/byte for 128-bit +@ key [on single-issue Xscale PXA250 core]. + +@ May 2007. +@ +@ AES_set_[en|de]crypt_key is added. + +@ July 2010. +@ +@ Rescheduling for dual-issue pipeline resulted in 12% improvement on +@ Cortex A8 core and ~25 cycles per byte processed with 128-bit key. + +@ February 2011. +@ +@ Profiler-assisted and platform-specific optimization resulted in 16% +@ improvement on Cortex A8 core and ~21.5 cycles per byte. + +@ A little glue here to select the correct code below for the ARM CPU +@ that is being targetted. + +.text +.code 32 + +.type AES_Te,%object +.align 5 +AES_Te: +.word 0xc66363a5, 0xf87c7c84, 0xee99, 0xf67b7b8d +.word 0xfff2f20d, 0xd66b6bbd, 0xde6f6fb1, 0x91c5c554 +.word 0x60303050, 0x02010103, 0xce6767a9, 0x562b2b7d +.word 0xe7fefe19, 0xb5d7d762, 0x4dababe6, 0xec76769a +.word 0x8fcaca45, 0x1f82829d, 0x89c9c940, 0xfa7d7d87 +.word 0xeffafa15, 0xb25959eb, 0x8e4747c9, 0xfbf0f00b +.word 0x41adadec, 0xb3d4d467, 0x5fa2a2fd, 0x45afafea +.word 0x239c9cbf, 0x53a4a4f7, 0xe4727296, 0x9bc0c05b +.word 0x75b7b7c2, 0xe1fdfd1c, 0x3d9393ae, 0x4c26266a +.word 0x6c36365a, 0x7e3f3f41, 0xf5f7f702, 0x834f +.word 0x6834345c, 0x51a5a5f4, 0xd1e5e534, 0xf9f1f108 +.word 0xe2717193, 0xabd8d873, 0x62313153, 0x2a15153f +.word 0x0804040c, 0x95c7c752, 0x46232365, 0x9dc3c35e +.word 0x30181828, 0x379696a1, 0x0a05050f, 0x2f9a9ab5 +.word 0x0e070709, 0x24121236, 0x1b80809b, 0xdfe2e23d +.word 0xcdebeb26, 0x4e272769, 0x7fb2b2cd, 0xea75759f +.word 0x1209091b, 0x1d83839e, 0x582c2c74, 0x341a1a2e +.word 0x361b1b2d, 0xdc6e6eb2, 0xb45a5aee, 0x5ba0a0fb +.word 0xa45252f6, 0x763b3b4d, 0xb7d6d661, 0x7db3b3ce +.word 0x5229297b, 0xdde3e33e, 0x5e2f2f71, 0x13848497 +.word 0xa65353f5, 0xb9d1d168, 0x, 0xc1eded2c +.word 0x40202060, 0xe3fcfc1f, 0x79b1b1c8, 0xb65b5bed +.word 0xd46a6abe, 0x8dcbcb46, 0x67bebed9, 0x7239394b +.word 0x944a4ade, 0x984c4cd4, 0xb05858e8, 0x85cfcf4a +.word 0xbbd0d06b, 0xc5efef2a, 0x4fe5, 0xedfbfb16 +.word 0x864343c5, 0x9a4d4dd7, 0x6655, 0x11858594 +.word 0x8a4545cf, 0xe9f9f910, 0x04020206, 0xfe7f7f81 +.word 0xa05050f0, 0x783c3c44, 0x259f9fba, 0x4ba8a8e3 +.word 0xa25151f3, 0x5da3a3fe, 0x804040c0, 0x058f8f8a +.word 0x3f9292ad, 0x219d9dbc, 0x70383848, 0xf1f5f504 +.word 0x63bcbcdf, 0x77b6b6c1, 0xafdada75, 0x42212163 +.word 0x20101030, 0xe51a, 0xfdf3f30e, 0xbfd2d26d +.word 0x81cdcd4c, 0x180c0c14, 0x26131335, 0xc3ecec2f +.word 0xbe5f5fe1, 0x359797a2, 0x88cc, 0x2e171739 +.word 0x93c4c457, 0x55a7a7f2, 0xfc7e7e82, 0x7a3d3d47 +.word 0xc86464ac, 0xba5d5de7, 0x3219192b, 0xe6737395 +.word 0xc06060a0, 0x19818198, 0x9e4f4fd1, 0xa3dcdc7f +.word 0x4466, 0x542a2a7e, 0x3b9090ab, 0x0b83 +.word 0x8c4646ca, 0xc729, 0x6bb8b8d3, 0x2814143c +.word 0xa7dede79, 0xbc5e5ee2, 0x160b0b1d, 0xaddbdb76 +.word 0xdbe0e03b, 0x64323256, 0x743a3a4e, 0x140a0a1e +.word 0x924949db, 0x0c06060a, 0x4824246c, 0xb85c5ce4 +.word 0x9fc2c25d, 0xbdd3d36e, 0x43acacef, 0xc46262a6 +.word 0x399191a8, 0x319595a4, 0xd3e4e437, 0xf279798b +.word 0xd5e7e732, 0x8bc8c843, 0x6e373759, 0xda6d6db7 +.word 0x018d8d8c, 0xb1d5d564, 0x9c4e4ed2, 0x49a9a9e0 +.word 0xd86c6cb4, 0xac5656fa, 0xf3f4f407, 0xcfeaea25 +.word 0xca6565af, 0xf47a7a8e, 0x47aeaee9, 0x10080818 +.word 0x6fbabad5, 0xf0787888, 0x4a25256f, 0x5c2e2e72 +.word 0x381c1c24, 0x57a6a6f1, 0x73b4b4c7, 0x97c6c651 +.word 0xcbe8e823, 0xa17c, 0xe874749c, 0x3e1f1f21 +.word 0x964b4bdd, 0x61bdbddc, 0x0d8b8b86, 0x0f8a8a85 +.word 0xe0707090, 0x7c3e3
[PATCH 1/1] arm/crypto: Add optimized AES and SHA1 routines
Add assembler versions of AES and SHA1 for ARM platforms. This has provided up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1. Platform CPU SPeedEndian Before (bps) After (bps) Improvement IXP425 533 MHz big 1121704215566294~38% KS8695 166 MHz little3828549 5795373~51% Signed-off-by: David McCullough ucde...@gmail.com --- diff -Npur linux-3.5.orig/arch/arm/crypto/aes-armv4.S linux-3.5/arch/arm/crypto/aes-armv4.S --- linux-3.5.orig/arch/arm/crypto/aes-armv4.S 1970-01-01 10:00:00.0 +1000 +++ linux-3.5/arch/arm/crypto/aes-armv4.S 2012-08-07 11:11:31.671359005 +1000 @@ -0,0 +1,1112 @@ +#define __ARM_ARCH__ __LINUX_ARM_ARCH__ +@ +@ Written by Andy Polyakov ap...@fy.chalmers.se for the OpenSSL +@ project. The module is, however, dual licensed under OpenSSL and +@ CRYPTOGAMS licenses depending on where you obtain it. For further +@ details see http://www.openssl.org/~appro/cryptogams/. +@ + +@ AES for ARMv4 + +@ January 2007. +@ +@ Code uses single 1K S-box and is 2 times faster than code generated +@ by gcc-3.4.1. This is thanks to unique feature of ARMv4 ISA, which +@ allows to merge logical or arithmetic operation with shift or rotate +@ in one instruction and emit combined result every cycle. The module +@ is endian-neutral. The performance is ~42 cycles/byte for 128-bit +@ key [on single-issue Xscale PXA250 core]. + +@ May 2007. +@ +@ AES_set_[en|de]crypt_key is added. + +@ July 2010. +@ +@ Rescheduling for dual-issue pipeline resulted in 12% improvement on +@ Cortex A8 core and ~25 cycles per byte processed with 128-bit key. + +@ February 2011. +@ +@ Profiler-assisted and platform-specific optimization resulted in 16% +@ improvement on Cortex A8 core and ~21.5 cycles per byte. + +@ A little glue here to select the correct code below for the ARM CPU +@ that is being targetted. + +.text +.code 32 + +.type AES_Te,%object +.align 5 +AES_Te: +.word 0xc66363a5, 0xf87c7c84, 0xee99, 0xf67b7b8d +.word 0xfff2f20d, 0xd66b6bbd, 0xde6f6fb1, 0x91c5c554 +.word 0x60303050, 0x02010103, 0xce6767a9, 0x562b2b7d +.word 0xe7fefe19, 0xb5d7d762, 0x4dababe6, 0xec76769a +.word 0x8fcaca45, 0x1f82829d, 0x89c9c940, 0xfa7d7d87 +.word 0xeffafa15, 0xb25959eb, 0x8e4747c9, 0xfbf0f00b +.word 0x41adadec, 0xb3d4d467, 0x5fa2a2fd, 0x45afafea +.word 0x239c9cbf, 0x53a4a4f7, 0xe4727296, 0x9bc0c05b +.word 0x75b7b7c2, 0xe1fdfd1c, 0x3d9393ae, 0x4c26266a +.word 0x6c36365a, 0x7e3f3f41, 0xf5f7f702, 0x834f +.word 0x6834345c, 0x51a5a5f4, 0xd1e5e534, 0xf9f1f108 +.word 0xe2717193, 0xabd8d873, 0x62313153, 0x2a15153f +.word 0x0804040c, 0x95c7c752, 0x46232365, 0x9dc3c35e +.word 0x30181828, 0x379696a1, 0x0a05050f, 0x2f9a9ab5 +.word 0x0e070709, 0x24121236, 0x1b80809b, 0xdfe2e23d +.word 0xcdebeb26, 0x4e272769, 0x7fb2b2cd, 0xea75759f +.word 0x1209091b, 0x1d83839e, 0x582c2c74, 0x341a1a2e +.word 0x361b1b2d, 0xdc6e6eb2, 0xb45a5aee, 0x5ba0a0fb +.word 0xa45252f6, 0x763b3b4d, 0xb7d6d661, 0x7db3b3ce +.word 0x5229297b, 0xdde3e33e, 0x5e2f2f71, 0x13848497 +.word 0xa65353f5, 0xb9d1d168, 0x, 0xc1eded2c +.word 0x40202060, 0xe3fcfc1f, 0x79b1b1c8, 0xb65b5bed +.word 0xd46a6abe, 0x8dcbcb46, 0x67bebed9, 0x7239394b +.word 0x944a4ade, 0x984c4cd4, 0xb05858e8, 0x85cfcf4a +.word 0xbbd0d06b, 0xc5efef2a, 0x4fe5, 0xedfbfb16 +.word 0x864343c5, 0x9a4d4dd7, 0x6655, 0x11858594 +.word 0x8a4545cf, 0xe9f9f910, 0x04020206, 0xfe7f7f81 +.word 0xa05050f0, 0x783c3c44, 0x259f9fba, 0x4ba8a8e3 +.word 0xa25151f3, 0x5da3a3fe, 0x804040c0, 0x058f8f8a +.word 0x3f9292ad, 0x219d9dbc, 0x70383848, 0xf1f5f504 +.word 0x63bcbcdf, 0x77b6b6c1, 0xafdada75, 0x42212163 +.word 0x20101030, 0xe51a, 0xfdf3f30e, 0xbfd2d26d +.word 0x81cdcd4c, 0x180c0c14, 0x26131335, 0xc3ecec2f +.word 0xbe5f5fe1, 0x359797a2, 0x88cc, 0x2e171739 +.word 0x93c4c457, 0x55a7a7f2, 0xfc7e7e82, 0x7a3d3d47 +.word 0xc86464ac, 0xba5d5de7, 0x3219192b, 0xe6737395 +.word 0xc06060a0, 0x19818198, 0x9e4f4fd1, 0xa3dcdc7f +.word 0x4466, 0x542a2a7e, 0x3b9090ab, 0x0b83 +.word 0x8c4646ca, 0xc729, 0x6bb8b8d3, 0x2814143c +.word 0xa7dede79, 0xbc5e5ee2, 0x160b0b1d, 0xaddbdb76 +.word 0xdbe0e03b, 0x64323256, 0x743a3a4e, 0x140a0a1e +.word 0x924949db, 0x0c06060a, 0x4824246c, 0xb85c5ce4 +.word 0x9fc2c25d, 0xbdd3d36e, 0x43acacef, 0xc46262a6 +.word 0x399191a8, 0x319595a4, 0xd3e4e437, 0xf279798b +.word 0xd5e7e732, 0x8bc8c843, 0x6e373759, 0xda6d6db7 +.word 0x018d8d8c, 0xb1d5d564, 0x9c4e4ed2, 0x49a9a9e0 +.word 0xd86c6cb4, 0xac5656fa, 0xf3f4f407, 0xcfeaea25 +.word 0xca6565af, 0xf47a7a8e, 0x47aeaee9, 0x10080818 +.word 0x6fbabad5, 0xf0787888, 0x4a25256f, 0x5c2e2e72 +.word 0x381c1c24, 0x57a6a6f1, 0x73b4b4c7, 0x97c6c651 +.word 0xcbe8e823, 0xa17c, 0xe874749c, 0x3e1f1f21 +.word 0x964b4bdd, 0x61bdbddc, 0x0d8b8b86, 0x0f8a8a85
Re: nommu: Add new vmalloc_user() and remap_vmalloc_range() interfaces.
Jivin Paul Mundt lays it down ...
> This builds on top of the earlier vmalloc_32_user() work introduced by
> b50731732f926d6c49fd0724616a7344c31cd5cf, as we now have places in the
> nommu allmodconfig that hit up against these missing APIs.
>
> As vmalloc_32_user() is already implemented, this is moved over to
> vmalloc_user() and simply made a wrapper. As all current nommu platforms
> are 32-bit addressable, there's no special casing we have to do for
> ZONE_DMA and things of that nature as per GFP_VMALLOC32.
>
> remap_vmalloc_range() needs to check VM_USERMAP in order to figure out
> whether we permit the remap or not, which means that we also have to
> rework the vmalloc_user() code to grovel for the VMA and set the flag.
Seems fine to me,
Cheers,
Davidm
Acked-by: David McCullough <[EMAIL PROTECTED]>
> Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
>
> ---
>
> mm/nommu.c | 45 -
> 1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 35622c5..c4768d0 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -10,6 +10,7 @@
> * Copyright (c) 2000-2003 David McCullough <[EMAIL PROTECTED]>
> * Copyright (c) 2000-2001 D Jeff Dionne <[EMAIL PROTECTED]>
> * Copyright (c) 2002 Greg Ungerer <[EMAIL PROTECTED]>
> + * Copyright (c) 2007 Paul Mundt <[EMAIL PROTECTED]>
> */
>
> #include
> @@ -183,6 +184,26 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask,
> pgprot_t prot)
> }
> EXPORT_SYMBOL(__vmalloc);
>
> +void *vmalloc_user(unsigned long size)
> +{
> + void *ret;
> +
> + ret = __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO,
> + PAGE_KERNEL);
> + if (ret) {
> + struct vm_area_struct *vma;
> +
> + down_write(>mm->mmap_sem);
> + vma = find_vma(current->mm, (unsigned long)ret);
> + if (vma)
> + vma->vm_flags |= VM_USERMAP;
> + up_write(>mm->mmap_sem);
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(vmalloc_user);
> +
> struct page * vmalloc_to_page(void *addr)
> {
> return virt_to_page(addr);
> @@ -253,10 +274,17 @@ EXPORT_SYMBOL(vmalloc_32);
> *
> * The resulting memory area is 32bit addressable and zeroed so it can be
> * mapped to userspace without leaking data.
> + *
> + * VM_USERMAP is set on the corresponding VMA so that subsequent calls to
> + * remap_vmalloc_range() are permissible.
> */
> void *vmalloc_32_user(unsigned long size)
> {
> - return __vmalloc(size, GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL);
> + /*
> + * We'll have to sort out the ZONE_DMA bits for 64-bit,
> + * but for now this can simply use vmalloc_user() directly.
> + */
> + return vmalloc_user(size);
> }
> EXPORT_SYMBOL(vmalloc_32_user);
>
> @@ -1213,6 +1241,21 @@ int remap_pfn_range(struct vm_area_struct *vma,
> unsigned long from,
> }
> EXPORT_SYMBOL(remap_pfn_range);
>
> +int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
> + unsigned long pgoff)
> +{
> + unsigned int size = vma->vm_end - vma->vm_start;
> +
> + if (!(vma->vm_flags & VM_USERMAP))
> + return -EINVAL;
> +
> + vma->vm_start = (unsigned long)(addr + (pgoff << PAGE_SHIFT));
> + vma->vm_end = vma->vm_start + size;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(remap_vmalloc_range);
> +
> void swap_unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
> {
> }
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: nommu: Add new vmalloc_user() and remap_vmalloc_range() interfaces.
Jivin Paul Mundt lays it down ...
This builds on top of the earlier vmalloc_32_user() work introduced by
b50731732f926d6c49fd0724616a7344c31cd5cf, as we now have places in the
nommu allmodconfig that hit up against these missing APIs.
As vmalloc_32_user() is already implemented, this is moved over to
vmalloc_user() and simply made a wrapper. As all current nommu platforms
are 32-bit addressable, there's no special casing we have to do for
ZONE_DMA and things of that nature as per GFP_VMALLOC32.
remap_vmalloc_range() needs to check VM_USERMAP in order to figure out
whether we permit the remap or not, which means that we also have to
rework the vmalloc_user() code to grovel for the VMA and set the flag.
Seems fine to me,
Cheers,
Davidm
Acked-by: David McCullough [EMAIL PROTECTED]
Signed-off-by: Paul Mundt [EMAIL PROTECTED]
---
mm/nommu.c | 45 -
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index 35622c5..c4768d0 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -10,6 +10,7 @@
* Copyright (c) 2000-2003 David McCullough [EMAIL PROTECTED]
* Copyright (c) 2000-2001 D Jeff Dionne [EMAIL PROTECTED]
* Copyright (c) 2002 Greg Ungerer [EMAIL PROTECTED]
+ * Copyright (c) 2007 Paul Mundt [EMAIL PROTECTED]
*/
#include linux/module.h
@@ -183,6 +184,26 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask,
pgprot_t prot)
}
EXPORT_SYMBOL(__vmalloc);
+void *vmalloc_user(unsigned long size)
+{
+ void *ret;
+
+ ret = __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | __GFP_ZERO,
+ PAGE_KERNEL);
+ if (ret) {
+ struct vm_area_struct *vma;
+
+ down_write(current-mm-mmap_sem);
+ vma = find_vma(current-mm, (unsigned long)ret);
+ if (vma)
+ vma-vm_flags |= VM_USERMAP;
+ up_write(current-mm-mmap_sem);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(vmalloc_user);
+
struct page * vmalloc_to_page(void *addr)
{
return virt_to_page(addr);
@@ -253,10 +274,17 @@ EXPORT_SYMBOL(vmalloc_32);
*
* The resulting memory area is 32bit addressable and zeroed so it can be
* mapped to userspace without leaking data.
+ *
+ * VM_USERMAP is set on the corresponding VMA so that subsequent calls to
+ * remap_vmalloc_range() are permissible.
*/
void *vmalloc_32_user(unsigned long size)
{
- return __vmalloc(size, GFP_KERNEL | __GFP_ZERO, PAGE_KERNEL);
+ /*
+ * We'll have to sort out the ZONE_DMA bits for 64-bit,
+ * but for now this can simply use vmalloc_user() directly.
+ */
+ return vmalloc_user(size);
}
EXPORT_SYMBOL(vmalloc_32_user);
@@ -1213,6 +1241,21 @@ int remap_pfn_range(struct vm_area_struct *vma,
unsigned long from,
}
EXPORT_SYMBOL(remap_pfn_range);
+int remap_vmalloc_range(struct vm_area_struct *vma, void *addr,
+ unsigned long pgoff)
+{
+ unsigned int size = vma-vm_end - vma-vm_start;
+
+ if (!(vma-vm_flags VM_USERMAP))
+ return -EINVAL;
+
+ vma-vm_start = (unsigned long)(addr + (pgoff PAGE_SHIFT));
+ vma-vm_end = vma-vm_start + size;
+
+ return 0;
+}
+EXPORT_SYMBOL(remap_vmalloc_range);
+
void swap_unplug_io_fn(struct backing_dev_info *bdi, struct page *page)
{
}
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Jivin Robin Getz lays it down ... > On Thu 20 Sep 2007 11:03, David McCullough pondered: > > I would say that (a) is definately not the case. I am sure the BF guys > > will say they have been banging us on the head with changes for a long > > time and getting no where as we considered the changes to severe or out > > of line. > > I don't think we have been "banging heads" with you (unless that is your > feeling?) - how about "working together, but diverting to satisfy different > needs" :) No head banging feelings here, but I would understand if you guys felt that way occasionally ;-) I obviously forgot the happy face on that statement. It was meant as a good thing. > I think that we have had more issues in the uClinux-dist (userspace and build > environment), but for kernel code, we have moved from some non-standard > (stupid) things we were doing early on to what we have today - which is as > common/standard with other archs as we can be. > > Although this is slightly off topic - on the uClinux distribution side - most > of our changes are based on requirements/desires from being able to support > fdpic elf and flat formats, and to attempt to make things easier for end > users/us to use/maintain. Where we do make changes - we always send the patch > upstream and have the conversation with you (not everyone else does this), > and some/most times rework things so they are more acceptable to you. We > don't always come to an agreement - but we always have the discussion, and > are willing to move if we can make things better that still meets both our > needs/desires. > > > This particular patch was trivial in comparison to others I've seen, > > That is what we thought. > > > it fixed all the existing arches (not something that is always done) and > > seemed a reasonable start to finally get the BF guys up and running. > > Still, happy to make it better of course ;-) > > As always - we are more than happy to explore/review alternative patches if > people want to write/sumbit them. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Jivin Paul Mundt lays it down ... ... > > The other maintainers who have spoken up didn't seem to think this was > > ugly, or an abuse. I'm surprised to hear language like that when > > discussing a patch that adds an if statement, a local variable and one > > parameter in a function call. > > > Yes, well, the scope of the changes is really rather irrelevant, it's the > technical basis behind it that should be the concern. My suggestion was > to lose the local variable, get rid of this "persistent" API, and plug in > something like flat_validate_relval() or something equally silly where > each architecture has the option to grab the relval and set up whatever > sort of state it wants to out-of-line. > > This is making API changes where it's convenient for your platform to use > this value, and there's no reason to change the API here at all. The > if/continue block are not an issue, it is the whole concept of persistent > data in this case that has no need to be applied uniformally across all > other architectures. > > Why should all architectures have to change their APIs (not just adding > new things mind you, also changing existing definitions) to accomodate > something that can trivially be kept in the blackfin code? Fair comment. I hadn't considered that it could be even cleaner. If it's easily doable then I agree with your concerns. > I wager the other maintainers either a) don't care because it doesn't > effect them, or b) have resigned binfmt_flat to its fate. Neither option > is particularly appealing in terms of getting that code tidied. That sort > of indifference is largely why binfmt_flat is as much of a mess as it is > today. Your patch is certainly not the cause of this, the architecture > callbacks there are just a mess to begin with, I would prefer that we try > to keep new additions flexible without blindly hardcoding more usage > assumptions all over the place and having to paper over them again later. I would say that (a) is definately not the case. I am sure the BF guys will say they have been banging us on the head with changes for a long time and getting no where as we considered the changes to severe or out of line. This particular patch was trivial in comparison to others I've seen, it fixed all the existing arches (not something that is always done) and seemed a reasonable start to finally get the BF guys up and running. Still, happy to make it better of course ;-) As for (b), I think it will be around for a while. It's not as flexible as fdpic, but it's still a tiny, simple format and not everyone has an fdpic implementation yet :-) Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Jivin Paul Mundt lays it down ... ... The other maintainers who have spoken up didn't seem to think this was ugly, or an abuse. I'm surprised to hear language like that when discussing a patch that adds an if statement, a local variable and one parameter in a function call. Yes, well, the scope of the changes is really rather irrelevant, it's the technical basis behind it that should be the concern. My suggestion was to lose the local variable, get rid of this persistent API, and plug in something like flat_validate_relval() or something equally silly where each architecture has the option to grab the relval and set up whatever sort of state it wants to out-of-line. This is making API changes where it's convenient for your platform to use this value, and there's no reason to change the API here at all. The if/continue block are not an issue, it is the whole concept of persistent data in this case that has no need to be applied uniformally across all other architectures. Why should all architectures have to change their APIs (not just adding new things mind you, also changing existing definitions) to accomodate something that can trivially be kept in the blackfin code? Fair comment. I hadn't considered that it could be even cleaner. If it's easily doable then I agree with your concerns. I wager the other maintainers either a) don't care because it doesn't effect them, or b) have resigned binfmt_flat to its fate. Neither option is particularly appealing in terms of getting that code tidied. That sort of indifference is largely why binfmt_flat is as much of a mess as it is today. Your patch is certainly not the cause of this, the architecture callbacks there are just a mess to begin with, I would prefer that we try to keep new additions flexible without blindly hardcoding more usage assumptions all over the place and having to paper over them again later. I would say that (a) is definately not the case. I am sure the BF guys will say they have been banging us on the head with changes for a long time and getting no where as we considered the changes to severe or out of line. This particular patch was trivial in comparison to others I've seen, it fixed all the existing arches (not something that is always done) and seemed a reasonable start to finally get the BF guys up and running. Still, happy to make it better of course ;-) As for (b), I think it will be around for a while. It's not as flexible as fdpic, but it's still a tiny, simple format and not everyone has an fdpic implementation yet :-) Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Jivin Robin Getz lays it down ... On Thu 20 Sep 2007 11:03, David McCullough pondered: I would say that (a) is definately not the case. I am sure the BF guys will say they have been banging us on the head with changes for a long time and getting no where as we considered the changes to severe or out of line. I don't think we have been banging heads with you (unless that is your feeling?) - how about working together, but diverting to satisfy different needs :) No head banging feelings here, but I would understand if you guys felt that way occasionally ;-) I obviously forgot the happy face on that statement. It was meant as a good thing. I think that we have had more issues in the uClinux-dist (userspace and build environment), but for kernel code, we have moved from some non-standard (stupid) things we were doing early on to what we have today - which is as common/standard with other archs as we can be. Although this is slightly off topic - on the uClinux distribution side - most of our changes are based on requirements/desires from being able to support fdpic elf and flat formats, and to attempt to make things easier for end users/us to use/maintain. Where we do make changes - we always send the patch upstream and have the conversation with you (not everyone else does this), and some/most times rework things so they are more acceptable to you. We don't always come to an agreement - but we always have the discussion, and are willing to move if we can make things better that still meets both our needs/desires. This particular patch was trivial in comparison to others I've seen, That is what we thought. it fixed all the existing arches (not something that is always done) and seemed a reasonable start to finally get the BF guys up and running. Still, happy to make it better of course ;-) As always - we are more than happy to explore/review alternative patches if people want to write/sumbit them. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED], Ph:+61 734352815 Secure Computing - SnapGear http://www.uCdot.org http://www.cyberguard.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Jivin Robin Getz lays it down ...
> On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
> > From: Bernd Schmidt <[EMAIL PROTECTED]>
> >
> > This just adds minimum support for the Blackfin relocations,
> > since we don't have enough space in each reloc. The idea
> > is to store a value with one relocation so that subsequent ones can
> > access it.
> >
> > Signed-off-by: Bernd Schmidt <[EMAIL PROTECTED]>
> > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]>
> > Cc: David McCullough <[EMAIL PROTECTED]>
> > Cc: Greg Ungerer <[EMAIL PROTECTED]>
>
> Adding the other appropriate maintainers. for h8, m32r, sh and v850.
Looks fine to me, obviously impacts the existing arches very little.
Can't see why it shouldn't get included,
Cheers,
Davidm
> > ---
> > fs/binfmt_flat.c |5 -
> > include/asm-h8300/flat.h |3 ++-
> > include/asm-m32r/flat.h |3 ++-
> > include/asm-m68knommu/flat.h |3 ++-
> > include/asm-sh/flat.h|3 ++-
> > include/asm-v850/flat.h |4 +++-
> > 6 files changed, 15 insertions(+), 6 deletions(-)
> > diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> > index 7b0265d..13b58f8 100644
> > --- a/fs/binfmt_flat.c
> > +++ b/fs/binfmt_flat.c
> > @@ -742,6 +742,7 @@ static int load_flat_file(struct linux_binprm * bprm,
> > * __start to address 4 so that is okay).
> > */
> > if (rev > OLD_FLAT_VERSION) {
> > + unsigned long persistent = 0;
> > for (i=0; i < relocs; i++) {
> > unsigned long addr, relval;
> >
> > @@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
> >relocated (of course, the address has to be
> >relocated first). */
> > relval = ntohl(reloc[i]);
> > + if (flat_set_persistent (relval, ))
> > + continue;
> > addr = flat_get_relocate_addr(relval);
> > rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
> > if (rp == (unsigned long *)RELOC_FAILED) {
> > @@ -757,7 +760,7 @@ static int load_flat_file(struct linux_binprm * bprm,
> > }
> >
> > /* Get the pointer's value. */
> > - addr = flat_get_addr_from_rp(rp, relval, flags);
> > + addr = flat_get_addr_from_rp(rp, relval, flags,
> > );
> > if (addr != 0) {
> > /*
> > * Do the relocation. PIC relocs in the data
> > section are
> > diff --git a/include/asm-h8300/flat.h b/include/asm-h8300/flat.h
> > index c20eee7..2a87350 100644
> > --- a/include/asm-h8300/flat.h
> > +++ b/include/asm-h8300/flat.h
> > @@ -9,6 +9,7 @@
> > #defineflat_argvp_envp_on_stack() 1
> > #defineflat_old_ram_flag(flags)1
> > #defineflat_reloc_valid(reloc, size) ((reloc) <= (size))
> > +#defineflat_set_persistent(relval, p) 0
> >
> > /*
> > * on the H8 a couple of the relocations have an instruction in the
> > @@ -18,7 +19,7 @@
> > */
> >
> > #defineflat_get_relocate_addr(rel) (rel)
> > -#define flat_get_addr_from_rp(rp, relval, flags) \
> > +#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
> > (get_unaligned(rp) & ((flags & FLAT_FLAG_GOTPIC) ? 0x:
> > 0x00ff))
> > #define flat_put_addr_at_rp(rp, addr, rel) \
> > put_unaligned (((*(char *)(rp)) << 24) | ((addr) & 0x00ff), rp)
> > diff --git a/include/asm-m32r/flat.h b/include/asm-m32r/flat.h
> > index 1b285f6..d851cf0 100644
> > --- a/include/asm-m32r/flat.h
> > +++ b/include/asm-m32r/flat.h
> > @@ -15,9 +15,10 @@
> > #defineflat_stack_align(sp)(*sp += (*sp & 3 ? (4 - (*sp &
> > 3)): 0))
> > #defineflat_argvp_envp_on_stack() 0
> > #defineflat_old_ram_flag(flags)(flags)
> > +#defineflat_set_persistent(relval, p) 0
> > #defineflat_reloc_valid(reloc, size) \
> > (((reloc) - textlen_for_m32r_lo16_data) <= (size))
> > -#define flat_get_addr_from_rp(rp, relval, flags) \
> > +#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
> > m32r_flat_get_addr_from_rp(rp, relval, (text_len) )
> >
> > #define flat_put_addr_at_rp(rp, add
Re: [PATCH] binfmt_flat: minimum support for theBlackfin relocations
Jivin Robin Getz lays it down ...
On Tue 18 Sep 2007 04:09, Bryan Wu pondered:
From: Bernd Schmidt [EMAIL PROTECTED]
This just adds minimum support for the Blackfin relocations,
since we don't have enough space in each reloc. The idea
is to store a value with one relocation so that subsequent ones can
access it.
Signed-off-by: Bernd Schmidt [EMAIL PROTECTED]
Signed-off-by: Bryan Wu [EMAIL PROTECTED]
Cc: David McCullough [EMAIL PROTECTED]
Cc: Greg Ungerer [EMAIL PROTECTED]
Adding the other appropriate maintainers. for h8, m32r, sh and v850.
Looks fine to me, obviously impacts the existing arches very little.
Can't see why it shouldn't get included,
Cheers,
Davidm
---
fs/binfmt_flat.c |5 -
include/asm-h8300/flat.h |3 ++-
include/asm-m32r/flat.h |3 ++-
include/asm-m68knommu/flat.h |3 ++-
include/asm-sh/flat.h|3 ++-
include/asm-v850/flat.h |4 +++-
6 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 7b0265d..13b58f8 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
@@ -742,6 +742,7 @@ static int load_flat_file(struct linux_binprm * bprm,
* __start to address 4 so that is okay).
*/
if (rev OLD_FLAT_VERSION) {
+ unsigned long persistent = 0;
for (i=0; i relocs; i++) {
unsigned long addr, relval;
@@ -749,6 +750,8 @@ static int load_flat_file(struct linux_binprm * bprm,
relocated (of course, the address has to be
relocated first). */
relval = ntohl(reloc[i]);
+ if (flat_set_persistent (relval, persistent))
+ continue;
addr = flat_get_relocate_addr(relval);
rp = (unsigned long *) calc_reloc(addr, libinfo, id, 1);
if (rp == (unsigned long *)RELOC_FAILED) {
@@ -757,7 +760,7 @@ static int load_flat_file(struct linux_binprm * bprm,
}
/* Get the pointer's value. */
- addr = flat_get_addr_from_rp(rp, relval, flags);
+ addr = flat_get_addr_from_rp(rp, relval, flags,
persistent);
if (addr != 0) {
/*
* Do the relocation. PIC relocs in the data
section are
diff --git a/include/asm-h8300/flat.h b/include/asm-h8300/flat.h
index c20eee7..2a87350 100644
--- a/include/asm-h8300/flat.h
+++ b/include/asm-h8300/flat.h
@@ -9,6 +9,7 @@
#defineflat_argvp_envp_on_stack() 1
#defineflat_old_ram_flag(flags)1
#defineflat_reloc_valid(reloc, size) ((reloc) = (size))
+#defineflat_set_persistent(relval, p) 0
/*
* on the H8 a couple of the relocations have an instruction in the
@@ -18,7 +19,7 @@
*/
#defineflat_get_relocate_addr(rel) (rel)
-#define flat_get_addr_from_rp(rp, relval, flags) \
+#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
(get_unaligned(rp) ((flags FLAT_FLAG_GOTPIC) ? 0x:
0x00ff))
#define flat_put_addr_at_rp(rp, addr, rel) \
put_unaligned (((*(char *)(rp)) 24) | ((addr) 0x00ff), rp)
diff --git a/include/asm-m32r/flat.h b/include/asm-m32r/flat.h
index 1b285f6..d851cf0 100644
--- a/include/asm-m32r/flat.h
+++ b/include/asm-m32r/flat.h
@@ -15,9 +15,10 @@
#defineflat_stack_align(sp)(*sp += (*sp 3 ? (4 - (*sp
3)): 0))
#defineflat_argvp_envp_on_stack() 0
#defineflat_old_ram_flag(flags)(flags)
+#defineflat_set_persistent(relval, p) 0
#defineflat_reloc_valid(reloc, size) \
(((reloc) - textlen_for_m32r_lo16_data) = (size))
-#define flat_get_addr_from_rp(rp, relval, flags) \
+#define flat_get_addr_from_rp(rp, relval, flags, persistent) \
m32r_flat_get_addr_from_rp(rp, relval, (text_len) )
#define flat_put_addr_at_rp(rp, addr, relval) \
diff --git a/include/asm-m68knommu/flat.h b/include/asm-m68knommu/flat.h
index 2d836ed..814b517 100644
--- a/include/asm-m68knommu/flat.h
+++ b/include/asm-m68knommu/flat.h
@@ -9,8 +9,9 @@
#defineflat_argvp_envp_on_stack() 1
#defineflat_old_ram_flag(flags)(flags)
#defineflat_reloc_valid(reloc, size) ((reloc) = (size))
-#defineflat_get_addr_from_rp(rp, relval, flags) get_unaligned(rp)
+#defineflat_get_addr_from_rp(rp, relval, flags, p) get_unaligned(rp)
#defineflat_put_addr_at_rp(rp, val, relval) put_unaligned(val,rp)
#defineflat_get_relocate_addr(rel) (rel)
+#defineflat_set_persistent(relval, p) 0
#endif /* __M68KNOMMU_FLAT_H__ */
diff --git
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ... ... > >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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ... ... 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ... > Evgeniy Polyakov wrote: > >On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote: > > > >>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. > > > > > >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: > > 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. 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ... > David McCullough wrote: > >Jivin Jeff Garzik lays it down ... > > > >>On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote: > >> > >>>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. > >> > >>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 ? > > All the apps are supposed to use /dev/random, so that's correct. Ok > 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Andrew Morton lays it down ... > David McCullough <[EMAIL PROTECTED]> wrote: > > > > 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. > 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc1] API for true Random Number Generators to add entropy
Hi 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
Signed-off-by: David McCullough <[EMAIL PROTECTED]>
--- linux-2.6.12-rc1.orig/drivers/char/random.c 2005-03-18 11:33:49.0
+1000
+++ linux-2.6.12-rc1/drivers/char/random.c 2005-03-24 16:16:40.0
+1000
@@ -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 = _pool;
+ if (r->entropy_count >= r->poolinfo->POOLBITS)
+ r = _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(_read_wait);
+}
+EXPORT_SYMBOL(add_true_randomness);
+
+/
*
* Sysctl interface
*
--- linux-2.6.12-rc1.orig/include/linux/random.h2005-03-18
11:34:37.0 +1000
+++ linux-2.6.12-rc1/include/linux/random.h 2005-03-24 15:59:42.0
+1000
@@ -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]);
--
David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc1] API for true Random Number Generators to add entropy
Hi 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
Signed-off-by: David McCullough [EMAIL PROTECTED]
--- linux-2.6.12-rc1.orig/drivers/char/random.c 2005-03-18 11:33:49.0
+1000
+++ linux-2.6.12-rc1/drivers/char/random.c 2005-03-24 16:16:40.0
+1000
@@ -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
*
--- linux-2.6.12-rc1.orig/include/linux/random.h2005-03-18
11:34:37.0 +1000
+++ linux-2.6.12-rc1/include/linux/random.h 2005-03-24 15:59:42.0
+1000
@@ -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]);
--
David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Andrew Morton lays it down ... David McCullough [EMAIL PROTECTED] wrote: 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. 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ... David McCullough wrote: Jivin Jeff Garzik lays it down ... On Thu, Mar 24, 2005 at 02:27:08PM +1000, David McCullough wrote: 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. 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 ? All the apps are supposed to use /dev/random, so that's correct. Ok 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] API for true Random Number Generators to add entropy (2.6.11)
Jivin Jeff Garzik lays it down ... Evgeniy Polyakov wrote: On Thu, 2005-03-24 at 14:27 +1000, David McCullough wrote: 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. 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: 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. 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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ocf-linux-20050324 - Asynchronous Crypto support for linux
Hi all, The latest release of ocf-linux (20050324) is available for download from the project page: http://ocf-linux.sourceforge.net/ This release includes the following changes: * Added random number generator support for the hifn and safenet drivers. * Added patch for 2.4/2.6 kernels to allow RNG code to add entropy easily, implements add_true_randomness in both kernels. * First working version of the Public Key routines on the safenet. * Fixed a couple of nasty bugs in the existing key framework/driver support. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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
Signed-off-by: David McCullough <[EMAIL PROTECTED]>
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
diff -u -r1.1.1.1 -r1.3
--- linux-2.4.29/include/linux/random.h 9 Jul 2001 00:39:16 - 1.1.1.1
+++ linux-2.4.29/include/linux/random.h 18 Mar 2005 04:33:35 - 1.3
@@ -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
diff -u -r1.1.1.9 -r1.11
--- linux-2.4.29/drivers/char/random.c 4 Feb 2005 00:28:36 - 1.1.1.9
+++ linux-2.4.29/drivers/char/random.c 18 Mar 2005 04:33:35 - 1.11
@@ -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(_read_wait);
+}
+EXPORT_SYMBOL(add_true_randomness);
+
/**
*
* Hash function definition
--
David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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
Signed-off-by: David McCullough <[EMAIL PROTECTED]>
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
diff -u -r1.1.1.6 random.h
--- linux-2.6.11/include/linux/random.h 3 Mar 2005 00:45:49 - 1.1.1.6
+++ linux-2.6.11/include/linux/random.h 18 Mar 2005 01:46:16 -
@@ -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
diff -u -r1.1.1.28 random.c
--- linux-2.6.11/drivers/char/random.c 3 Mar 2005 00:45:31 - 1.1.1.28
+++ linux-2.6.11/drivers/char/random.c 18 Mar 2005 01:46:16 -
@@ -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(_read_wait);
+}
+EXPORT_SYMBOL(add_true_randomness);
+
/**
*
* Hash function definition
--
David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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
Signed-off-by: David McCullough [EMAIL PROTECTED]
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
diff -u -r1.1.1.6 random.h
--- linux-2.6.11/include/linux/random.h 3 Mar 2005 00:45:49 - 1.1.1.6
+++ linux-2.6.11/include/linux/random.h 18 Mar 2005 01:46:16 -
@@ -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
diff -u -r1.1.1.28 random.c
--- linux-2.6.11/drivers/char/random.c 3 Mar 2005 00:45:31 - 1.1.1.28
+++ linux-2.6.11/drivers/char/random.c 18 Mar 2005 01:46:16 -
@@ -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
--
David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 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
Signed-off-by: David McCullough [EMAIL PROTECTED]
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
diff -u -r1.1.1.1 -r1.3
--- linux-2.4.29/include/linux/random.h 9 Jul 2001 00:39:16 - 1.1.1.1
+++ linux-2.4.29/include/linux/random.h 18 Mar 2005 04:33:35 - 1.3
@@ -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
diff -u -r1.1.1.9 -r1.11
--- linux-2.4.29/drivers/char/random.c 4 Feb 2005 00:28:36 - 1.1.1.9
+++ linux-2.4.29/drivers/char/random.c 18 Mar 2005 04:33:35 - 1.11
@@ -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
--
David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ocf-linux-20050324 - Asynchronous Crypto support for linux
Hi all, The latest release of ocf-linux (20050324) is available for download from the project page: http://ocf-linux.sourceforge.net/ This release includes the following changes: * Added random number generator support for the hifn and safenet drivers. * Added patch for 2.4/2.6 kernels to allow RNG code to add entropy easily, implements add_true_randomness in both kernels. * First working version of the Public Key routines on the safenet. * Fixed a couple of nasty bugs in the existing key framework/driver support. Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ocf-linux-20050315 - Asynchronous Crypto support for linux
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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ocf-linux-20050315 - Asynchronous Crypto support for linux
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 -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time
Jivin James Morris lays it down ... > On Thu, 20 Jan 2005, David McCullough wrote: > > > As for permission to use a dual license, I will gladly approach the > > authors if others feel it is important to know the possibility of it at this > > point, > > Please do so. It would be useful to have the option of using an already > developed, debugged and analyzed framework. Ok, I finally managed to get responses from all the individual contributors, though none of the corporations contacted have responded. While a good number of those contacted were happy to dual-license, most are concerned that changes made under the GPL will not be available for use in BSD. A couple were a definate no. I have had offers to rewrite any portions that can not be dual-licensed, but I think that is overkill for now unless there is significant interest in taking that path. Fortunately we have been able to obtain some funding to complete a large amount of work on the project so it should have some nice progress in the next couple of weeks as that ramps up :-) Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time
Jivin James Morris lays it down ... On Thu, 20 Jan 2005, David McCullough wrote: As for permission to use a dual license, I will gladly approach the authors if others feel it is important to know the possibility of it at this point, Please do so. It would be useful to have the option of using an already developed, debugged and analyzed framework. Ok, I finally managed to get responses from all the individual contributors, though none of the corporations contacted have responded. While a good number of those contacted were happy to dual-license, most are concerned that changes made under the GPL will not be available for use in BSD. A couple were a definate no. I have had offers to rewrite any portions that can not be dual-licensed, but I think that is overkill for now unless there is significant interest in taking that path. Fortunately we have been able to obtain some funding to complete a large amount of work on the project so it should have some nice progress in the next couple of weeks as that ramps up :-) Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time
Jivin James Morris lays it down ... > On Sat, 15 Jan 2005, Fruhwirth Clemens wrote: > > > However, developing two different APIs isn't particular efficient. I > > know, at the moment there isn't much choice, as J.Morris hasn't commited > > to acrypto in anyway. > > There is also the OCF port (OpenBSD crypto framework) to consider, if > permission to dual license from the original authors can be obtained. For anyone looking for the OCF port for linux, you can find the latest release here: http://lists.logix.cz/pipermail/cryptoapi/2004/000261.html One of the drivers uses the existing kernel crypto API to implement a SW crypto engine for OCF. As for permission to use a dual license, I will gladly approach the authors if others feel it is important to know the possibility of it at this point, Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] CryptoAPI: prepare for processing multiple buffers at a time
Jivin James Morris lays it down ... On Sat, 15 Jan 2005, Fruhwirth Clemens wrote: However, developing two different APIs isn't particular efficient. I know, at the moment there isn't much choice, as J.Morris hasn't commited to acrypto in anyway. There is also the OCF port (OpenBSD crypto framework) to consider, if permission to dual license from the original authors can be obtained. For anyone looking for the OCF port for linux, you can find the latest release here: http://lists.logix.cz/pipermail/cryptoapi/2004/000261.html One of the drivers uses the existing kernel crypto API to implement a SW crypto engine for OCF. As for permission to use a dual license, I will gladly approach the authors if others feel it is important to know the possibility of it at this point, Cheers, Davidm -- David McCullough, [EMAIL PROTECTED] Ph:+61 7 34352815 http://www.SnapGear.com Custom Embedded Solutions + Security Fx:+61 7 38913630 http://www.uCdot.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
