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]

Re: [ANNOUNCEMENT] New package: rng-tools-5-1


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]