[ANNOUNCEMENT] New package: rng-tools-5-1
Wed Aug 13 08:55:00 GMT 2014
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
I found out that I need to preserve (at least) %rdi and %rsi in the
>> 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
>> 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
> 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. :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4334 bytes
Desc: not available
-------------- next part --------------
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin