Mail Archives: cygwin/2014/08/13/05:43:35
--BQPnanjtCNWHyqYD
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi Peter,
On Aug 13 10:55, Peter Rosin wrote:
> On 2014-08-12 16:11, Corinna Vinschen wrote:
> > Hi Peter,
> >=20
> > 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.
>=20
> 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 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.s=
rc/rng-tools-5-1.i686/src/rng-tools-5/configure: line 4335: ac_fn_c_try_lin=
k: command not found
> >> /usr/src/rng-tools-5-1.src/rng-tools-5-1.i686/src/rng-tools-5/configur=
e: 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.
> >=20
> > 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.
>=20
> 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.
>=20
> > 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.
>=20
> 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.
>=20
> > Ultimately I gave up on rngd for now, for four reasons:
> >=20
> > - 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.
>=20
> 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 >=3D 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.
>=20
> 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
application.
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=20
> > in our home with a TPM chip *and* a functional Windows driver,
> > there was no matching cryptographic provider returned by the call
> > to CryptEnumProviders.
>=20
> Sorry, I have no input on the other HW entropy sources.
>=20
> > - 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.
> >=20
> > 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=20
> > this on the cygwin-developer's list.
>=20
> 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
--=20
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--BQPnanjtCNWHyqYD
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJT6zMvAAoJEPU2Bp2uRE+gmaIP/0QxVObypnsQh3rvIQPwa2MF
hQHTxs9/hTnG8SVr2t4C5YKIK+1Erdq1tt9iwsD79uNnAorjtwUxuaUDKz/9cSxg
yEIlIjGRT7wT0g8tj+TxIVo9mKHfhIuoVYRShr4hcYeX3xJufI7PUtBXkSzRLSdb
6uckg0EjLfw1CHjqZuaG3Ac5Wu1Ll4DqF2/2bAY7XyINiRTLZQXJ8M5+cH8g1A4p
9JATTXRrx327U42kOElXhP6rhZtJ3lz168yATJ9816kbWRMSRcEeXnpIa+QoC4F8
RJAUwDMxUHQMv5SXXIFIjuCgD2e4XPxwegVVnT3XxmXWojA/KaBLH0gT8aikDVHP
gMz//LllF8I/F4hf2oit8x+RUNWGjmG3tZkDnS1Corh7wrspps3IuhmUyzs3S4Zi
g1uF5JTHbh4i4C5OOXv2EFd3t5Ct1rR1IYDGOhq3jiUq8mn9SJ/wW24U+KWpO0QK
ix6lnH4UprFcoq+LnNofTnt5RTVGQ8QYII23a1lyy5RqGYpVt+2Gy1Xq3ABuWUZ9
ydrKNB1LtOgnvkFjkPzJ9XrK1nhgTOx14aNLlsVMysOJmILtsHv6x2J6pwuYCDMt
f15ERF0tqINyS26tg14pFk9KnUj/k59nvXU6l9Q4PLjn80rHpwYDhCJQImKPmqSV
ZeQnH2B334q956TL/X+n
=LjRg
-----END PGP SIGNATURE-----
--BQPnanjtCNWHyqYD--
- Raw text -