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