This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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:
rdrand_win_asm.S
Description: Text document
Attachment:
pgpBhzhjJUoF5.pgp
Description: PGP signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |