* [ANNOUNCEMENT] New package: rng-tools-5-1 @ 2014-08-09 14:50 Corinna Vinschen 2014-08-12 13:29 ` Peter Rosin 0 siblings, 1 reply; 8+ messages in thread From: Corinna Vinschen @ 2014-08-09 14:50 UTC (permalink / raw) To: cygwin Hi folks, I just uploaded rng-tools-5-1. The Cygwin release only comes with the rngtest tool for now. The rngd daemon requires porting assembler code to COFF and the Microsoft calling convention. Any help porting this code would be greatly appreciated. Have fun, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-09 14:50 [ANNOUNCEMENT] New package: rng-tools-5-1 Corinna Vinschen @ 2014-08-12 13:29 ` Peter Rosin 2014-08-12 14:11 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Peter Rosin @ 2014-08-12 13:29 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1340 bytes --] On 2014-08-09 16:37, Corinna Vinschen wrote: > I just uploaded rng-tools-5-1. > > The Cygwin release only comes with the rngtest tool for now. > > The rngd daemon requires porting assembler code to COFF and the > Microsoft calling convention. Any help porting this code would > be greatly appreciated. Ok, I took a stab at it. The problems I identified in the assembly are ELF debug info, different register use for the x86-64 calls and a missing underscore prefix for the i686 symbols. I'm unsure if used registers (and which) have to be saved in the MS x86-64 ABI, but that shouldn't be too hard to fix if that's the case. I also moved up the AC_SEARCH_LIBS hunk in configure.ac since the existing AC_CHECK_LIB is buried inside some other construct (AC_CHECK_HEADER is possibly the culprit) which causes this: checking for library containing argp_parse... /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found no Anyway, with the attached patch instead of the one included in the src package, it builds for both arches, but my cpu appears to lack the rdrand instruction, so I have a hard time taking this any further. Bummer. Cheers, Peter [-- Attachment #2: cygwin-rng-tools-5-peda.patch --] [-- Type: text/x-patch, Size: 3464 bytes --] diff -rup origsrc/rng-tools-5/configure.ac src/rng-tools-5/configure.ac --- origsrc/rng-tools-5/configure.ac 2014-08-12 10:33:32.064585400 +0200 +++ src/rng-tools-5/configure.ac 2014-08-12 11:18:44.431782000 +0200 @@ -56,6 +56,8 @@ dnl ------------------------------------ dnl Checks for optional library functions dnl ------------------------------------- +AC_SEARCH_LIBS([argp_parse],[argp]) + dnl ------------------------------------- dnl Check for libgcrypt support dnl ------------------------------------- diff -rup origsrc/rng-tools-5/rdrand_asm.S src/rng-tools-5/rdrand_asm.S --- origsrc/rng-tools-5/rdrand_asm.S 2014-08-12 10:33:32.066585400 +0200 +++ src/rng-tools-5/rdrand_asm.S 2014-08-12 11:26:27.429381800 +0200 @@ -20,20 +20,41 @@ #if defined(__i386__) || defined(__x86_64__) -#define ENTRY(x) \ - .balign 64 ; \ - .globl x ; \ -x: +#if defined __CYGWIN__ +# if defined __x86_64__ +# define MS_x86_64_ABI +# else +# define SYMBOL(name) _ ## name +# endif +#else +# define ELF_DEBUG_INFO +#endif +#if !defined SYMBOL +# define SYMBOL(name) name +#endif + +#define ENTRY(x) \ + .balign 64 ; \ + .globl SYMBOL(x) ; \ +SYMBOL(x): +#if defined ELF_DEBUG_INFO #define ENDPROC(x) \ .size x, .-x ; \ .type x, @function +#else +#define ENDPROC(x) +#endif #define RDRAND_RETRY_LIMIT 10 #ifdef __x86_64__ ENTRY(x86_rdrand_bytes) +#if defined MS_x86_64_ABI + mov %rcx, %rdi + mov %rdx, %rsi +#endif mov %esi, %eax 1: mov $RDRAND_RETRY_LIMIT, %ecx @@ -55,6 +76,12 @@ ENDPROC(x86_rdrand_bytes) ENTRY(x86_rdseed_or_rdrand_bytes) +#if defined MS_x86_64_ABI + mov %rcx, %rdi + mov %rdx, %rsi + mov %r8, %rdx + mov %r9, %rcx +#endif mov (%rsi), %r8d /* RDSEED count */ mov (%rcx), %r9d /* RDRAND count */ 1: @@ -191,6 +218,10 @@ movl 12(%ebp), %edx push %esi #endif +#if defined MS_x86_64_ABI + mov %rcx, %rdi + mov %rdx, %rsi +#endif movl $512, CTR3 /* Number of rounds */ movdqa (0*16)(PTR1), %xmm0 @@ -295,6 +326,9 @@ mov %esp, %ebp movl 8(%ebp), %eax #endif +#if defined MS_x86_64_ABI + mov %rcx, %rdi +#endif SETPTR(aes_round_keys, PTR1) movdqu (PTR0), %xmm0 @@ -347,12 +381,16 @@ .balign 64 aes_round_keys: .space 11*16 +#if defined ELF_DEBUG_INFO .size aes_round_keys, .-aes_round_keys +#endif /* ELF_DEBUG_INFO */ #endif /* i386 or x86_64 */ +#if defined ELF_DEBUG_INFO /* * This is necessary to keep the whole executable * from needing a writable stack. */ .section .note.GNU-stack,"",%progbits +#endif /* ELF_DEBUG_INFO */ diff -rup origsrc/rng-tools-5/rngd_linux.c src/rng-tools-5/rngd_linux.c --- origsrc/rng-tools-5/rngd_linux.c 2012-08-06 19:04:12.000000000 +0200 +++ src/rng-tools-5/rngd_linux.c 2014-08-09 15:09:21.081616358 +0200 @@ -39,8 +39,10 @@ #include <fcntl.h> #include <sys/time.h> #include <time.h> +#ifndef __CYGWIN__ #include <linux/types.h> #include <linux/random.h> +#endif #include <string.h> #include "rngd.h" @@ -130,11 +132,19 @@ void random_add_entropy(void *buf, size_ entropy.size = size; memcpy(entropy.data, buf, size); +#ifdef __CYGWIN__ + if (write(random_fd, entropy.data, size) != size) { + message(LOG_DAEMON|LOG_ERR, "Add Entropy failed: %s\n", + strerror(errno)); + exit(1); + } +#else if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) { message(LOG_DAEMON|LOG_ERR, "RNDADDENTROPY failed: %s\n", strerror(errno)); exit(1); } +#endif } void random_sleep(void) [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-12 13:29 ` Peter Rosin @ 2014-08-12 14:11 ` Corinna Vinschen 2014-08-12 14:26 ` Corinna Vinschen 2014-08-13 8:55 ` Peter Rosin 0 siblings, 2 replies; 8+ messages in thread From: Corinna Vinschen @ 2014-08-12 14:11 UTC (permalink / raw) To: cygwin [-- Attachment #1.1: Type: text/plain, Size: 3347 bytes --] Hi Peter, On Aug 12 15:29, Peter Rosin wrote: > On 2014-08-09 16:37, Corinna Vinschen wrote: > > I just uploaded rng-tools-5-1. > > > > The Cygwin release only comes with the rngtest tool for now. > > > > The rngd daemon requires porting assembler code to COFF and the > > Microsoft calling convention. Any help porting this code would > > be greatly appreciated. > > Ok, I took a stab at it. The problems I identified in the assembly > are ELF debug info, different register use for the x86-64 calls and > a missing underscore prefix for the i686 symbols. > > I'm unsure if used registers (and which) have to be saved in the > MS x86-64 ABI, but that shouldn't be too hard to fix if that's the > case. > > I also moved up the AC_SEARCH_LIBS hunk in configure.ac since > the existing AC_CHECK_LIB is buried inside some other construct > (AC_CHECK_HEADER is possibly the culprit) which causes this: > > checking for library containing argp_parse... /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found > /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found > no > > Anyway, with the attached patch instead of the one included in the > src package, it builds for both arches, but my cpu appears to lack > the rdrand instruction, so I have a hard time taking this any > further. Bummer. Thanks for your efforts! Over the weekend I tried my own port. I opted for creating a new file, rdrand_win_asm.S (attached for reference) to keep the code a bit cleaner. I have a machine which supports the rdrand call, but you need at least an Ivy Bridge CPU, For rdseed you need at least Haswell. Ultimately I gave up on rngd for now, for four reasons: - rngd uses poll(2) on /dev/random to wait until /dev/random becomes writable. /dev/random on Cygwin is always writable (we're not controlling the entropy pool, the OS does, and the RtlGenRandom call never blocks). This results in 100% CPU usage. - Even then, using rngd on /dev/random gave *worse* results when testing /dev/random with rngtest :-P I'm not sure why. - Cygwin does not support any of the other three hardware entropy sources /dev/hwrng or /dev/tpm0. For Intel/AMD hwrng you'd need access to the PCI bus and certain chipsets. For tpm0 you'd need a TPM chip and a description how to access the chip for producing random numbers. The chip is supposedly available as cryptographic provider under Windows, but on the only machine in our home with a TPM chip *and* a functional Windows driver, there was no matching cryptographic provider returned by the call to CryptEnumProviders. - Given that, and given the hardware constraints for the rdrand and rdseed calls, I decided that it's not worth to follow through with this stuff. Still, thanks a lot for working on that. I appreciate it. If you have any idea how Cygwin could provide /dev/hwrng or /dev/tpm0 to have at least two HW entropy sources, please feel free to discuss this on the cygwin-developer's list. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #1.2: rdrand_win_asm.S --] [-- Type: text/plain, Size: 7075 bytes --] /* * Copyright (c) 2011-2014, Intel Corporation * Authors: Fenghua Yu <fenghua.yu@intel.com>, * H. Peter Anvin <hpa@linux.intel.com> * * This program is free software; you can redistribute it and/or modify it * under the terms and conditions of the GNU General Public License, * version 2, as published by the Free Software Foundation. * * This program is distributed in the hope it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for * more details. * * You should have received a copy of the GNU General Public License along with * this program; if not, write to the Free Software Foundation, Inc., * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. * */ /* * This is the Windows version of the file. It's equivalent to the original * code from Intel, just replacing ELF with COFF pseudo code expressions * where necessary and using Windows ABI rather than System V ABI on x86_64. * Additionally it utilizes the fact that recent versions of gas know the * rdrand, rdseed, and aes opcodes to avoid opaque .byte expression. */ #if defined(__i386__) || defined(__x86_64__) #ifdef __x86_64__ #define LBL(x) x #else #define LBL(x) _##x #endif #define ENTRY(x) \ .align 8 ; \ .globl LBL(x) ; \ .def LBL(x) ; \ .scl 2 ; \ .type 32 ; \ .endef ; \ LBL(x): #define ENDPROC(x) #define RDRAND_RETRY_LIMIT 10 #ifdef __x86_64__ ENTRY(x86_rdrand_bytes) mov %edx, %eax 1: mov $RDRAND_RETRY_LIMIT, %r9d 2: rdrand %r10 jnc 3f mov %r10, (%rcx) add $8, %rcx sub $8, %edx ja 1b 4: sub %edx, %eax ret 3: dec %r9d rep;nop jnz 2b jmp 4b ENDPROC(x86_rdrand_bytes) ENTRY(x86_rdseed_or_rdrand_bytes) push %r12 push %r13 mov (%rdx), %r12d /* RDSEED count */ mov (%r9), %r13d /* RDRAND count */ 1: mov $RDRAND_RETRY_LIMIT, %r10d 2: rdrand %rax jnc 3f mov %rax, (%rcx) add $8, %rcx sub $8, %r12d ja 1b 4: sub %r12d, (%rdx) sub %r13d, (%r9) pop %r13 pop %r12 ret 3: rdrand %rax jnc 5f mov %rax, (%r8) add $8, %r8 sub $8, %r13d ja 1b jmp 4b 5: dec %r10d rep;nop jnz 2b jmp 4b ENDPROC(x86_rdseed_or_rdrand_bytes) #define SETPTR(var,ptr) leaq var(%rip),ptr #define PTR0 %rcx #define PTR1 %rdx #define PTR2 %r9 #define CTR3 %eax #define NPTR2 1 /* %rcx = %r1, only 0-7 valid here */ #elif defined(__i386__) ENTRY(x86_rdrand_bytes) push %ebp mov %esp, %ebp push %edi push %esi movl 8(%ebp), %edi movl 12(%ebp), %esi mov %esi, %eax 1: mov $RDRAND_RETRY_LIMIT, %ecx 2: rdrand %edx jnc 3f mov %edx, (%edi) add $4, %edi sub $4, %esi ja 1b 4: sub %esi, %eax pop %esi pop %edi pop %ebp ret 3: dec %ecx rep;nop jnz 2b jmp 4b ENDPROC(x86_rdrand_bytes) ENTRY(x86_rdseed_or_rdrand_bytes) push %ebp mov %esp, %ebp push %edi push %esi push %ebx mov 12(%ebp), %ebx mov 20(%ebp), %esi mov 8(%ebp), %edi /* RDSEED pointer */ mov 16(%ebp), %edx /* RDRAND pointer */ mov (%ebx), %ebx /* RDSEED count */ mov (%esi), %esi /* RDRAND count */ 1: mov $RDRAND_RETRY_LIMIT, %ecx 2: rdseed %eax jnc 3f mov %eax, (%edi) add $4, %edi sub $4, %ebx ja 1b 4: mov 12(%ebp), %edx mov 20(%ebp), %eax sub %ebx, (%edx) /* RDSEED count */ sub %esi, (%eax) /* RDRAND count */ pop %ebx pop %esi pop %edi pop %ebp ret 3: rdrand %eax jnc 5f mov %eax, (%edx) add $4, %edx sub $4, %esi jnz 1b ja 4b 5: dec %ecx rep;nop jnz 2b jmp 4b ENDPROC(x86_rdseed_or_rdrand_bytes) #define SETPTR(var,ptr) movl $(var),ptr #define PTR0 %eax #define PTR1 %edx #define PTR2 %ecx #define CTR3 %esi #define NPTR2 1 /* %rcx = %r1 */ #endif ENTRY(x86_aes_mangle) #ifdef __i386__ push %ebp mov %esp, %ebp movl 8(%ebp), %eax movl 12(%ebp), %edx push %esi #endif movl $512, CTR3 /* Number of rounds */ movdqa (0*16)(PTR1), %xmm0 movdqa (1*16)(PTR1), %xmm1 movdqa (2*16)(PTR1), %xmm2 movdqa (3*16)(PTR1), %xmm3 movdqa (4*16)(PTR1), %xmm4 movdqa (5*16)(PTR1), %xmm5 movdqa (6*16)(PTR1), %xmm6 movdqa (7*16)(PTR1), %xmm7 #ifdef __x86_64__ SETPTR(aes_round_keys, PTR2) 1: #else 1: SETPTR(aes_round_keys, PTR2) #endif /* 8192 = 512 (rounds) * 16 (bytes) */ pxor (0*8192)(PTR0), %xmm0 pxor (1*8192)(PTR0), %xmm1 pxor (2*8192)(PTR0), %xmm2 pxor (3*8192)(PTR0), %xmm3 pxor (4*8192)(PTR0), %xmm4 pxor (5*8192)(PTR0), %xmm5 pxor (6*8192)(PTR0), %xmm6 pxor (7*8192)(PTR0), %xmm7 add $16, PTR0 offset = 0 .rept 10 #ifdef __x86_64__ movdqa offset(PTR2), %xmm8 offset = offset + 16 aesenc %xmm8, %xmm0 aesenc %xmm8, %xmm1 aesenc %xmm8, %xmm2 aesenc %xmm8, %xmm3 aesenc %xmm8, %xmm4 aesenc %xmm8, %xmm5 aesenc %xmm8, %xmm6 aesenc %xmm8, %xmm7 #else aesenc (PTR2), %xmm0 aesenc (PTR2), %xmm1 aesenc (PTR2), %xmm2 aesenc (PTR2), %xmm3 aesenc (PTR2), %xmm4 aesenc (PTR2), %xmm5 aesenc (PTR2), %xmm6 aesenc (PTR2), %xmm7 add $16, PTR2 #endif .endr #ifdef __x86_64__ movdqa offset(PTR2), %xmm8 aesenclast %xmm8, %xmm0 aesenclast %xmm8, %xmm1 aesenclast %xmm8, %xmm2 aesenclast %xmm8, %xmm3 aesenclast %xmm8, %xmm4 aesenclast %xmm8, %xmm5 aesenclast %xmm8, %xmm6 aesenclast %xmm8, %xmm7 #else aesenclast (PTR2), %xmm0 aesenclast (PTR2), %xmm1 aesenclast (PTR2), %xmm2 aesenclast (PTR2), %xmm3 aesenclast (PTR2), %xmm4 aesenclast (PTR2), %xmm5 aesenclast (PTR2), %xmm6 aesenclast (PTR2), %xmm7 #endif sub $1, CTR3 jnz 1b movdqa %xmm0, (0*16)(PTR1) movdqa %xmm1, (1*16)(PTR1) movdqa %xmm2, (2*16)(PTR1) movdqa %xmm3, (3*16)(PTR1) movdqa %xmm4, (4*16)(PTR1) movdqa %xmm5, (5*16)(PTR1) movdqa %xmm6, (6*16)(PTR1) movdqa %xmm7, (7*16)(PTR1) #ifdef __i386__ pop %esi pop %ebp #endif ret ENDPROC(x86_aes_mangle) ENTRY(x86_aes_expand_key) #ifdef __i386__ push %ebp mov %esp, %ebp movl 8(%ebp), %eax #endif SETPTR(aes_round_keys, PTR1) movdqu (PTR0), %xmm0 movdqa %xmm0, (PTR1) /* First slot = the plain key */ add $16, PTR1 aeskeygenassist $0x01,%xmm0,%xmm1 call 1f aeskeygenassist $0x02,%xmm0,%xmm1 call 1f aeskeygenassist $0x04,%xmm0,%xmm1 call 1f aeskeygenassist $0x08,%xmm0,%xmm1 call 1f aeskeygenassist $0x10,%xmm0,%xmm1 call 1f aeskeygenassist $0x20,%xmm0,%xmm1 call 1f aeskeygenassist $0x40,%xmm0,%xmm1 call 1f aeskeygenassist $0x80,%xmm0,%xmm1 call 1f aeskeygenassist $0x1b,%xmm0,%xmm1 call 1f aeskeygenassist $0x36,%xmm0,%xmm1 call 1f #ifdef __i386__ pop %ebp #endif ret 1: pshufd $0xff, %xmm1, %xmm1 movdqa %xmm0, %xmm2 pslldq $4, %xmm2 pxor %xmm2, %xmm0 pslldq $4, %xmm2 pxor %xmm2, %xmm0 pslldq $4, %xmm2 pxor %xmm2, %xmm0 pxor %xmm1, %xmm0 movdqa %xmm0, (PTR1) add $16, PTR1 ret ENDPROC(x86_aes_expand_key) .bss .balign 64 aes_round_keys: .space 11*16 #endif /* i386 or x86_64 */ [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-12 14:11 ` Corinna Vinschen @ 2014-08-12 14:26 ` Corinna Vinschen 2014-08-13 8:55 ` Peter Rosin 1 sibling, 0 replies; 8+ messages in thread From: Corinna Vinschen @ 2014-08-12 14:26 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 372 bytes --] On Aug 12 16:11, Corinna Vinschen wrote: > I have a machine which supports the rdrand call, but you need at least > an Ivy Bridge CPU, For rdseed you need at least Haswell. s/Haswell/Broadwell/ Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-12 14:11 ` Corinna Vinschen 2014-08-12 14:26 ` Corinna Vinschen @ 2014-08-13 8:55 ` Peter Rosin 2014-08-13 9:43 ` Corinna Vinschen 1 sibling, 1 reply; 8+ messages in thread From: Peter Rosin @ 2014-08-13 8:55 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 4074 bytes --] On 2014-08-12 16:11, Corinna Vinschen wrote: > Hi Peter, > > On Aug 12 15:29, Peter Rosin wrote: >> On 2014-08-09 16:37, Corinna Vinschen wrote: >>> I just uploaded rng-tools-5-1. >>> >>> The Cygwin release only comes with the rngtest tool for now. >>> >>> The rngd daemon requires porting assembler code to COFF and the >>> Microsoft calling convention. Any help porting this code would >>> be greatly appreciated. >> >> Ok, I took a stab at it. The problems I identified in the assembly >> are ELF debug info, different register use for the x86-64 calls and >> a missing underscore prefix for the i686 symbols. >> >> I'm unsure if used registers (and which) have to be saved in the >> MS x86-64 ABI, but that shouldn't be too hard to fix if that's the >> case. I found out that I need to preserve (at least) %rdi and %rsi in the callee. >> I also moved up the AC_SEARCH_LIBS hunk in configure.ac since >> the existing AC_CHECK_LIB is buried inside some other construct >> (AC_CHECK_HEADER is possibly the culprit) which causes this: >> >> checking for library containing argp_parse... /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found >> /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found >> no >> >> Anyway, with the attached patch instead of the one included in the >> src package, it builds for both arches, but my cpu appears to lack >> the rdrand instruction, so I have a hard time taking this any >> further. Bummer. > > Thanks for your efforts! Over the weekend I tried my own port. I opted > for creating a new file, rdrand_win_asm.S (attached for reference) to > keep the code a bit cleaner. And I didn't want to fork it, for easier maintenance. Your version ought to be faster though, without all the thunking going on in my version. > I have a machine which supports the rdrand call, but you need at least > an Ivy Bridge CPU, For rdseed you need at least Haswell. I found an Haswell upstairs (but no Broadwell, so still no rdseed). For completeness, I'm attaching a version of my patch that makes it actually run. > Ultimately I gave up on rngd for now, for four reasons: > > - rngd uses poll(2) on /dev/random to wait until /dev/random becomes > writable. /dev/random on Cygwin is always writable (we're not > controlling the entropy pool, the OS does, and the RtlGenRandom call > never blocks). This results in 100% CPU usage. Yes, I saw that full core usage as well when I ran rngd... > - Even then, using rngd on /dev/random gave *worse* results when > testing /dev/random with rngtest :-P I'm not sure why. Yes, I saw that too. Maybe the reason is that if you could get a better PRNG by adding a feedback of the output to the entropy pool, that would already be part of the PRNG? I'm not into PRNGs though... > - Cygwin does not support any of the other three hardware entropy > sources /dev/hwrng or /dev/tpm0. For Intel/AMD hwrng you'd need > access to the PCI bus and certain chipsets. For tpm0 you'd > need a TPM chip and a description how to access the chip for > producing random numbers. The chip is supposedly available as > cryptographic provider under Windows, but on the only machine > in our home with a TPM chip *and* a functional Windows driver, > there was no matching cryptographic provider returned by the call > to CryptEnumProviders. Sorry, I have no input on the other HW entropy sources. > - Given that, and given the hardware constraints for the rdrand and > rdseed calls, I decided that it's not worth to follow through with > this stuff. > > Still, thanks a lot for working on that. I appreciate it. If you > have any idea how Cygwin could provide /dev/hwrng or /dev/tpm0 to > have at least two HW entropy sources, please feel free to discuss > this on the cygwin-developer's list. This seemed like something I could waste a little time on, and learn something in the process. Which I did, so not all is lost. :-) Cheers, Peter [-- Attachment #2: cygwin-rng-tools-5-peda.patch --] [-- Type: text/x-patch, Size: 4334 bytes --] diff -rup origsrc/rng-tools-5/configure.ac src/rng-tools-5/configure.ac --- origsrc/rng-tools-5/configure.ac 2014-08-12 10:33:32.064585400 +0200 +++ src/rng-tools-5/configure.ac 2014-08-12 11:18:44.431782000 +0200 @@ -56,6 +56,8 @@ dnl ------------------------------------ dnl Checks for optional library functions dnl ------------------------------------- +AC_SEARCH_LIBS([argp_parse],[argp]) + dnl ------------------------------------- dnl Check for libgcrypt support dnl ------------------------------------- diff -rup origsrc/rng-tools-5/rdrand_asm.S src/rng-tools-5/rdrand_asm.S --- origsrc/rng-tools-5/rdrand_asm.S 2014-08-13 10:16:08.499091900 +0200 +++ src/rng-tools-5/rdrand_asm.S 2014-08-13 10:12:40.745403500 +0200 @@ -20,20 +20,43 @@ #if defined(__i386__) || defined(__x86_64__) -#define ENTRY(x) \ - .balign 64 ; \ - .globl x ; \ -x: +#if defined __CYGWIN__ +# if defined __x86_64__ +# define MS_x86_64_ABI +# else +# define SYMBOL(name) _ ## name +# endif +#else +# define ELF_DEBUG_INFO +#endif +#if !defined SYMBOL +# define SYMBOL(name) name +#endif + +#define ENTRY(x) \ + .balign 64 ; \ + .globl SYMBOL(x) ; \ +SYMBOL(x): +#if defined ELF_DEBUG_INFO #define ENDPROC(x) \ .size x, .-x ; \ .type x, @function +#else +#define ENDPROC(x) +#endif #define RDRAND_RETRY_LIMIT 10 #ifdef __x86_64__ ENTRY(x86_rdrand_bytes) +#if defined MS_x86_64_ABI + push %rdi + push %rsi + mov %rcx, %rdi + mov %rdx, %rsi +#endif mov %esi, %eax 1: mov $RDRAND_RETRY_LIMIT, %ecx @@ -46,6 +69,10 @@ ENTRY(x86_rdrand_bytes) ja 1b 4: sub %esi, %eax +#if defined MS_x86_64_ABI + pop %rsi + pop %rdi +#endif ret 3: dec %ecx @@ -55,6 +82,14 @@ ENTRY(x86_rdrand_bytes) ENDPROC(x86_rdrand_bytes) ENTRY(x86_rdseed_or_rdrand_bytes) +#if defined MS_x86_64_ABI + push %rdi + push %rsi + mov %rcx, %rdi + mov %rdx, %rsi + mov %r8, %rdx + mov %r9, %rcx +#endif mov (%rsi), %r8d /* RDSEED count */ mov (%rcx), %r9d /* RDRAND count */ 1: @@ -69,6 +104,10 @@ ENTRY(x86_rdseed_or_rdrand_bytes) 4: sub %r8d, (%rsi) sub %r9d, (%rcx) +#if defined MS_x86_64_ABI + pop %rsi + pop %rdi +#endif ret 3: .byte 0x48,0x0f,0xc7,0xf0 /* rdrand %rax */ @@ -191,6 +230,12 @@ ENTRY(x86_aes_mangle) movl 12(%ebp), %edx push %esi #endif +#if defined MS_x86_64_ABI + push %rdi + push %rsi + mov %rcx, %rdi + mov %rdx, %rsi +#endif movl $512, CTR3 /* Number of rounds */ movdqa (0*16)(PTR1), %xmm0 @@ -283,6 +328,10 @@ offset = offset + 16 pop %esi pop %ebp #endif +#if defined MS_x86_64_ABI + pop %rsi + pop %rdi +#endif ret ENDPROC(x86_aes_mangle) @@ -295,6 +344,11 @@ ENTRY(x86_aes_expand_key) mov %esp, %ebp movl 8(%ebp), %eax #endif +#if defined MS_x86_64_ABI + push %rdi + push %rsi + mov %rcx, %rdi +#endif SETPTR(aes_round_keys, PTR1) movdqu (PTR0), %xmm0 @@ -325,6 +379,10 @@ ENTRY(x86_aes_expand_key) #ifdef __i386__ pop %ebp #endif +#if defined MS_x86_64_ABI + pop %rsi + pop %rdi +#endif ret 1: @@ -347,12 +405,16 @@ ENDPROC(x86_aes_expand_key) .balign 64 aes_round_keys: .space 11*16 +#if defined ELF_DEBUG_INFO .size aes_round_keys, .-aes_round_keys +#endif /* ELF_DEBUG_INFO */ #endif /* i386 or x86_64 */ +#if defined ELF_DEBUG_INFO /* * This is necessary to keep the whole executable * from needing a writable stack. */ .section .note.GNU-stack,"",%progbits +#endif /* ELF_DEBUG_INFO */ diff -rup origsrc/rng-tools-5/rngd_linux.c src/rng-tools-5/rngd_linux.c --- origsrc/rng-tools-5/rngd_linux.c 2012-08-06 19:04:12.000000000 +0200 +++ src/rng-tools-5/rngd_linux.c 2014-08-09 15:09:21.081616358 +0200 @@ -39,8 +39,10 @@ #include <fcntl.h> #include <sys/time.h> #include <time.h> +#ifndef __CYGWIN__ #include <linux/types.h> #include <linux/random.h> +#endif #include <string.h> #include "rngd.h" @@ -130,11 +132,19 @@ void random_add_entropy(void *buf, size_ entropy.size = size; memcpy(entropy.data, buf, size); +#ifdef __CYGWIN__ + if (write(random_fd, entropy.data, size) != size) { + message(LOG_DAEMON|LOG_ERR, "Add Entropy failed: %s\n", + strerror(errno)); + exit(1); + } +#else if (ioctl(random_fd, RNDADDENTROPY, &entropy) != 0) { message(LOG_DAEMON|LOG_ERR, "RNDADDENTROPY failed: %s\n", strerror(errno)); exit(1); } +#endif } void random_sleep(void) [-- Attachment #3: Type: text/plain, Size: 218 bytes --] -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-13 8:55 ` Peter Rosin @ 2014-08-13 9:43 ` Corinna Vinschen 2014-08-14 10:09 ` Peter Rosin 0 siblings, 1 reply; 8+ messages in thread From: Corinna Vinschen @ 2014-08-13 9:43 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 6102 bytes --] Hi Peter, On Aug 13 10:55, Peter Rosin wrote: > On 2014-08-12 16:11, Corinna Vinschen wrote: > > Hi Peter, > > > > On Aug 12 15:29, Peter Rosin wrote: > >> On 2014-08-09 16:37, Corinna Vinschen wrote: > >>> I just uploaded rng-tools-5-1. > >>> > >>> The Cygwin release only comes with the rngtest tool for now. > >>> > >>> The rngd daemon requires porting assembler code to COFF and the > >>> Microsoft calling convention. Any help porting this code would > >>> be greatly appreciated. > >> > >> Ok, I took a stab at it. The problems I identified in the assembly > >> are ELF debug info, different register use for the x86-64 calls and > >> a missing underscore prefix for the i686 symbols. > >> > >> I'm unsure if used registers (and which) have to be saved in the > >> MS x86-64 ABI, but that shouldn't be too hard to fix if that's the > >> case. > > I found out that I need to preserve (at least) %rdi and %rsi in the > callee. Yeah, that's necessary. I tried to use r10 in my version at one point because it's defined as volatile register. > >> I also moved up the AC_SEARCH_LIBS hunk in configure.ac since > >> the existing AC_CHECK_LIB is buried inside some other construct > >> (AC_CHECK_HEADER is possibly the culprit) which causes this: > >> > >> checking for library containing argp_parse... /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found > >> /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_link: command not found > >> no > >> > >> Anyway, with the attached patch instead of the one included in the > >> src package, it builds for both arches, but my cpu appears to lack > >> the rdrand instruction, so I have a hard time taking this any > >> further. Bummer. > > > > Thanks for your efforts! Over the weekend I tried my own port. I opted > > for creating a new file, rdrand_win_asm.S (attached for reference) to > > keep the code a bit cleaner. > > And I didn't want to fork it, for easier maintenance. Your version ought > to be faster though, without all the thunking going on in my version. > > > I have a machine which supports the rdrand call, but you need at least > > an Ivy Bridge CPU, For rdseed you need at least Haswell. > > I found an Haswell upstairs (but no Broadwell, so still no rdseed). For > completeness, I'm attaching a version of my patch that makes it actually > run. > > > Ultimately I gave up on rngd for now, for four reasons: > > > > - rngd uses poll(2) on /dev/random to wait until /dev/random becomes > > writable. /dev/random on Cygwin is always writable (we're not > > controlling the entropy pool, the OS does, and the RtlGenRandom call > > never blocks). This results in 100% CPU usage. > > Yes, I saw that full core usage as well when I ran rngd... This would need a hack^Wworkaround in Cygwin to work as expected. In theory, Cygwin could pretend the entropy pool is 4K in size. Every write to /dev/random increments a byte count, every read decrements the byte count. If the entropy pool is "full" (byte count >= 4K), the write, select, and poll calls could block. It wouldn't even be too much code, but I'm a bit stuck right now between a rewrite of Cygwin's EFAULT handling, the AD integration thingy, and updating Cygwin to 1.7.32 to support C++11 thread_local handling so it might take some time. > > - Even then, using rngd on /dev/random gave *worse* results when > > testing /dev/random with rngtest :-P I'm not sure why. > > Yes, I saw that too. Maybe the reason is that if you could get a better > PRNG by adding a feedback of the output to the entropy pool, that > would already be part of the PRNG? I'm not into PRNGs though... Me neither. AFAIK, RtlGenRandom provides a CSPRNG. It gets automatically reseeded at least once per 128K bytes read. It uses some arbitrary data for that (timestamps, etc) combined with the data in the buffer given to RtlGenRandom. To improve /dev/random, Cygwin calls RtlGenRandom twice in each call, once with a dummy 128K buffer to enforce reseeding, and then once to return the data to the calling application. Maybe this activity collides with seeding the PRNG from another entropy source somehow. And maybe the constant calling of RtlGenRandom in a tighht loop (due to the poll problem) doesn't help either. But that's just guessing on a high level :} > > - Cygwin does not support any of the other three hardware entropy > > sources /dev/hwrng or /dev/tpm0. For Intel/AMD hwrng you'd need > > access to the PCI bus and certain chipsets. For tpm0 you'd > > need a TPM chip and a description how to access the chip for > > producing random numbers. The chip is supposedly available as > > cryptographic provider under Windows, but on the only machine > > in our home with a TPM chip *and* a functional Windows driver, > > there was no matching cryptographic provider returned by the call > > to CryptEnumProviders. > > Sorry, I have no input on the other HW entropy sources. > > > - Given that, and given the hardware constraints for the rdrand and > > rdseed calls, I decided that it's not worth to follow through with > > this stuff. > > > > Still, thanks a lot for working on that. I appreciate it. If you > > have any idea how Cygwin could provide /dev/hwrng or /dev/tpm0 to > > have at least two HW entropy sources, please feel free to discuss > > this on the cygwin-developer's list. > > This seemed like something I could waste a little time on, and learn > something in the process. Which I did, so not all is lost. :-) Cool! I'm glad for any help, you know. If you want to take over the rng-tools package to play further with it, feel free. I'll look into the fake entropy pool size in a not so distant future. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-13 9:43 ` Corinna Vinschen @ 2014-08-14 10:09 ` Peter Rosin 2014-08-14 11:25 ` Corinna Vinschen 0 siblings, 1 reply; 8+ messages in thread From: Peter Rosin @ 2014-08-14 10:09 UTC (permalink / raw) To: cygwin On 2014-08-13 11:43, Corinna Vinschen wrote: > On Aug 13 10:55, Peter Rosin wrote: >> This seemed like something I could waste a little time on, and learn >> something in the process. Which I did, so not all is lost. :-) Ok, I see how the above could be misread easily, since it appeared in the context it did. But the key to interpreting it is that it is all past tense; it was meant as a comment to the whole thread. > Cool! I'm glad for any help, you know. If you want to take over > the rng-tools package to play further with it, feel free. I'll > look into the fake entropy pool size in a not so distant future. What I'm saying is that I have no further input. Sorry. Figuring out how to write device drivers or otherwise access the PCI bus is not something I have done previously (not for any current Windows version anyway), and it feels too much like a black hole regarding time. So, again, sorry if that's disappointing. That said, I could still adopt the rng-tools package if that would be any help (but I don't see myself hacking on any new HW features) Cheers, Peter -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [ANNOUNCEMENT] New package: rng-tools-5-1 2014-08-14 10:09 ` Peter Rosin @ 2014-08-14 11:25 ` Corinna Vinschen 0 siblings, 0 replies; 8+ messages in thread From: Corinna Vinschen @ 2014-08-14 11:25 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 1507 bytes --] On Aug 14 12:09, Peter Rosin wrote: > On 2014-08-13 11:43, Corinna Vinschen wrote: > > On Aug 13 10:55, Peter Rosin wrote: > >> This seemed like something I could waste a little time on, and learn > >> something in the process. Which I did, so not all is lost. :-) > > Ok, I see how the above could be misread easily, since it appeared in > the context it did. But the key to interpreting it is that it is all > past tense; it was meant as a comment to the whole thread. > > > Cool! I'm glad for any help, you know. If you want to take over > > the rng-tools package to play further with it, feel free. I'll > > look into the fake entropy pool size in a not so distant future. > > What I'm saying is that I have no further input. Sorry. Figuring > out how to write device drivers or otherwise access the PCI bus > is not something I have done previously (not for any current Windows > version anyway), and it feels too much like a black hole regarding > time. So, again, sorry if that's disappointing. Yeah, but no worries. > That said, I could still adopt the rng-tools package if that would > be any help (but I don't see myself hacking on any new HW features) Only if you like. I'm not trying to press gang you into service, though I'm glad for each package taken over by an active maintainer of course. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-08-14 11:25 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-08-09 14:50 [ANNOUNCEMENT] New package: rng-tools-5-1 Corinna Vinschen 2014-08-12 13:29 ` Peter Rosin 2014-08-12 14:11 ` Corinna Vinschen 2014-08-12 14:26 ` Corinna Vinschen 2014-08-13 8:55 ` Peter Rosin 2014-08-13 9:43 ` Corinna Vinschen 2014-08-14 10:09 ` Peter Rosin 2014-08-14 11:25 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).