* [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).