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 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 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

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 Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

Attachment: pgpyP3QJFz5N1.pgp
Description: PGP signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]