From jussi.kivilinna at mbnet.fi  Sat Dec  1 12:21:15 2012
From: jussi.kivilinna at mbnet.fi (Jussi Kivilinna)
Date: Sat, 01 Dec 2012 13:21:15 +0200
Subject: [PATCH 1/2] Optimize buffer xoring.
In-Reply-To: <87pq2w70xz.fsf@vigenere.g10code.de>
References: <20121129153709.7099.62541.stgit@localhost6.localdomain6>
	<87pq2w70xz.fsf@vigenere.g10code.de>
Message-ID: <20121201132115.29702hylkngm65og@www.dalek.fi>

Quoting Werner Koch <wk at gnupg.org>:

>> +#if defined(__i386__) || defined(__x86_64__)
>> +/* These architechtures are able of unaligned memory accesses and can
>> +   handle those fast.
>> + */
>
> Really?  All of them?
>

I've now tested AMD Phenom II (32/64bit), Intel Core2 (32/64bit),  
Intel Sandy Bridge (32/64bit) and Intel Atom (32bit) for unaligned  
accesses/buf_xor, and all do reasonably well. Intel Core2 seems to  
have highest penality (2.0x more time) for unaligned buf_xor on small  
buffers (16 bytes). However it's still faster than byte-xor, that  
takes 4.0x more time than aligned buf_xor with 16 bytes buffers.

I have attached the source of tool I used to do the measurements.

-Jussi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_unaligned.c
Type: text/x-csrc
Size: 6998 bytes
Desc: not available
URL: </pipermail/attachments/20121201/7fed12b9/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 665 bytes
Desc: PGP Digital Signature
URL: </pipermail/attachments/20121201/7fed12b9/attachment.pgp>

From wk at gnupg.org  Mon Dec  3 14:31:19 2012
From: wk at gnupg.org (Werner Koch)
Date: Mon, 03 Dec 2012 14:31:19 +0100
Subject: [PATCH] Fix building with CC="gcc -std=c90".
In-Reply-To: <20121129195534.26810.71478.stgit@localhost6.localdomain6> (Jussi
	Kivilinna's message of "Thu, 29 Nov 2012 21:55:34 +0200")
References: <20121129195534.26810.71478.stgit@localhost6.localdomain6>
Message-ID: <87ehj71cuw.fsf@vigenere.g10code.de>

On Thu, 29 Nov 2012 20:55, jussi.kivilinna at mbnet.fi said:
> * configure.ac: Add check for missing 'asm' keyword in C90 mode and
> replacement with '__asm__'.

Applied.  Thanks,


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Mon Dec  3 20:58:22 2012
From: wk at gnupg.org (Werner Koch)
Date: Mon, 03 Dec 2012 20:58:22 +0100
Subject: New RNG in Libgcrypt
Message-ID: <87sj7mzz4x.fsf@vigenere.g10code.de>

Hi,

I just pushed a change for 1.6 which allows to select a different RNG
type.  Here is the commit message:

    random: Add a RNG selection interface and system RNG wrapper.
    
    * random/random-system.c: New.
    * random/Makefile.am (librandom_la_SOURCES): Add new module.
    * random/random.c (struct rng_types): New.
    (_gcry_set_preferred_rng_type, _gcry_get_rng_type): New.
    (_gcry_random_initialize, gcry_random_add_bytes, do_randomize)
    (_gcry_set_random_seed_file, _gcry_update_random_seed_file)
    (_gcry_fast_random_poll): Dispatch to the actual RNG.
    * src/gcrypt.h.in (GCRYCTL_SET_PREFERRED_RNG_TYPE): New.
    GCRYCTL_GET_CURRENT_RNG_TYPE): New.
    (gcry_rng_types): New.
    * src/global.c (print_config): Print the TNG type.
    (global_init, _gcry_vcontrol): Implement the new control codes.
    * doc/gcrypt.texi (Controlling the library): Document the new control
    codes.
    
    * tests/benchmark.c (main): Add options to test the RNG types.
    * tests/random.c (main): Add new options.
    (print_hex): Print to stderr.
    (progress_cb, rng_type): New.
    (check_rng_type_switching, check_early_rng_type_switching): New.
    (run_all_rng_tests): New.
    --
    
    The purpose of this change is to allow applications with moderate
    random requirements to use the system's RNG (e.g. /dev/urandom).  The
    type switching logic makes sure that existing applications won't be
    affected by this change.  A library is in almost all cases not able to
    degrade the quality of the RNG.  The definition of "degrade" comes
    from our own assertion of the quality/trustworthiness of the RNGs:
    
    The most trustworthy RNG is the CSPRNG which dates back to the early
    GnuPG days.  It is quite conservative and often requires more seeding
    than might be justified.  GCRY_RNG_TYPE_STANDARD is the default unless
    the process is in FIPS mode.
    
    The second trustworthy RNG is the FIPS recommended X9.81 AES based
    implementation.  It is seeded by the system's RNG.  GCRY_RNG_TYPE_FIPS
    is the only available RNG if running in FIPS mode.
    
    The third trustworthy RNG is a mere wrapper around the system's native
    RNG.  Thus there is no extra step on top of what, for example,
    /dev/random provides.  GCRY_RNG_TYPE_SYSTEM may be used by
    applications which would use /dev/random or /dev/urandom instead.

Any comments or questions?


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Wed Dec  5 12:24:09 2012
From: wk at gnupg.org (Werner Koch)
Date: Wed, 05 Dec 2012 12:24:09 +0100
Subject: DCO for Werner Koch
Message-ID: <87obi8u4h2.fsf@vigenere.g10code.de>

Libgcrypt Developer's Certificate of Origin.  Version 1.0
=========================================================

By making a contribution to the Libgcrypt project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: Werner Koch <wk at gnupg.org>

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 204 bytes
Desc: not available
URL: </pipermail/attachments/20121205/52fcf54d/attachment.pgp>

From fabriciolelis at gmail.com  Fri Dec  7 16:05:05 2012
From: fabriciolelis at gmail.com (=?ISO-8859-1?Q?Fabr=EDcio_L=E9lis?=)
Date: Fri, 7 Dec 2012 12:05:05 -0300
Subject: this is a bug (md.c:969:md_read)
Message-ID: <CAFpUbKg_+hBh8ve9NQ0wv3nm67dk_OG81AkF6dhiV7azsjYuzA@mail.gmail.com>

Anybody can help me with this?

Ohhhh jeeee: ... this is a bug (md.c:969:md_read)
Aborted (core dumped)

Thanks!
-- 
Fabr?cio Gutemberg L?lis de Melo
Master Candidate in Computer Science at UFCG
Research at GAD( Dedicated Architectures Group ) - www.lad.dsc.ufcg.edu.br
http://fabriciolelis.googlepages.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121207/333d47e7/attachment-0001.htm>

From bradh at frogmouth.net  Sat Dec  8 00:12:09 2012
From: bradh at frogmouth.net (Brad Hards)
Date: Sat, 8 Dec 2012 10:12:09 +1100
Subject: this is a bug (md.c:969:md_read)
In-Reply-To: <CAFpUbKg_+hBh8ve9NQ0wv3nm67dk_OG81AkF6dhiV7azsjYuzA@mail.gmail.com>
References: <CAFpUbKg_+hBh8ve9NQ0wv3nm67dk_OG81AkF6dhiV7azsjYuzA@mail.gmail.com>
Message-ID: <201212081012.09886.bradh@frogmouth.net>

On Saturday 08 December 2012 02:05:05 Fabr?cio L?lis wrote:
> Ohhhh jeeee: ... this is a bug (md.c:969:md_read)
> Aborted (core dumped)
Some more context might help. What application? What version of gcrypt? Any 
local changes? What host environment (operating system, system libraries)? 
What compiler? Anything special happening?

Brad


From phajdan.jr at chromium.org  Thu Dec 13 01:25:28 2012
From: phajdan.jr at chromium.org (=?UTF-8?B?UGF3ZcWCIEhhamRhbiwgSnIu?=)
Date: Wed, 12 Dec 2012 16:25:28 -0800
Subject: thread-safety when used by a library
Message-ID: <CAATLsPaeU_1pXZw-juOrUqUMuXX+WmBcVcrimE1A+VZeaz2rGw@mail.gmail.com>

I've noticed http://bugs.g10code.com/gnupg/issue1197 and would be
interested in helping to fix that bug.

Could you share a general plan how would you like to deal with that issue?
Would you accept patches to get things fully fixed?

Pawe? Hajdan, Jr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20121212/55fd8e62/attachment.htm>

From wk at gnupg.org  Thu Dec 13 11:35:04 2012
From: wk at gnupg.org (Werner Koch)
Date: Thu, 13 Dec 2012 11:35:04 +0100
Subject: thread-safety when used by a library
In-Reply-To: <CAATLsPaeU_1pXZw-juOrUqUMuXX+WmBcVcrimE1A+VZeaz2rGw@mail.gmail.com>
	(=?utf-8?Q?=22Pawe=C5=82?= Hajdan, Jr."'s message of "Wed, 12 Dec 2012
	16:25:28 -0800")
References: <CAATLsPaeU_1pXZw-juOrUqUMuXX+WmBcVcrimE1A+VZeaz2rGw@mail.gmail.com>
Message-ID: <87obhyb5pj.fsf@vigenere.g10code.de>

On Thu, 13 Dec 2012 01:25, phajdan.jr at chromium.org said:

> Could you share a general plan how would you like to deal with that issue?

This has already been fixed in Libgcrypt master.  There are still the
usual problems with libraries and pthreads left (e.g. the not 100%
solvable problems with fork and pthread).

One think I am still thinking about is to use semaphores instead of
mutex.  They don't have the pthread problems and are sufficient for
Libgcrypt purposes.  The only drawback I can see is the requirement to
link against librt.  nPth uses semaphores so at least for GnuPG 2.1 it
is a link dependency anyway.

> Would you accept patches to get things fully fixed?

Yes.  See doc/HACKING.


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From nmav at gnutls.org  Thu Dec 13 16:29:27 2012
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 13 Dec 2012 16:29:27 +0100
Subject: thread-safety when used by a library
In-Reply-To: <87obhyb5pj.fsf@vigenere.g10code.de>
References: <CAATLsPaeU_1pXZw-juOrUqUMuXX+WmBcVcrimE1A+VZeaz2rGw@mail.gmail.com>
	<87obhyb5pj.fsf@vigenere.g10code.de>
Message-ID: <CAJU7zaKO0sC+dWtc0FY--him3H=nre29ABhxZkrPiPyFTwziZw@mail.gmail.com>

On Thu, Dec 13, 2012 at 11:35 AM, Werner Koch <wk at gnupg.org> wrote:

>> Could you share a general plan how would you like to deal with that issue?
> This has already been fixed in Libgcrypt master.  There are still the
> usual problems with libraries and pthreads left (e.g. the not 100%
> solvable problems with fork and pthread).
> One think I am still thinking about is to use semaphores instead of
> mutex.  They don't have the pthread problems and are sufficient for
> Libgcrypt purposes.  The only drawback I can see is the requirement to
> link against librt.  nPth uses semaphores so at least for GnuPG 2.1 it
> is a link dependency anyway.

I think that the mutex is particularly suited for that usage, compared
to semaphore. Since you don't care about locks across processes having
semaphores would not provide any advantage, and I'd expect also
mutexes to be more efficient in threads than semaphores. We use
mutexes in gnutls for locking (and critical sections in windows) with
no issues so far (applications with special needs can always override
the provided locks with their own, but I'm not aware of any doing
that).

About the the issues with fork and pthreads, I think they cannot be
solved by a library and users who mix them should figure a proper
initialization sequence anyway. Applications that do that maybe should
be allowed to register their own locks they can control (I don't think
there's is a great deal of such applications though).

regards,
Nikos


From dmitry.kasatkin at intel.com  Fri Dec 14 09:39:01 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Fri, 14 Dec 2012 10:39:01 +0200
Subject: DCO
Message-ID: <CALLzPKatdjVzHHQqmJV0k6jw2=DBZxJsxzE=V=eh868bWZuY4g@mail.gmail.com>

Hello,

I sent PGP signed message in PGP/MIME format and do not see that it
was delivered.
Checking if normal email is delivered.

- Dmitry


From dmitry.kasatkin at intel.com  Fri Dec 14 09:27:07 2012
From: dmitry.kasatkin at intel.com (Dmitry Kasatkin)
Date: Fri, 14 Dec 2012 10:27:07 +0200
Subject: DCO
Message-ID: <50CAE2DB.80302@intel.com>

Hello,

Here is my DCO.

- Dmitry

-------------- next part --------------
Libgcrypt Developer's Certificate of Origin.  Version 1.0
=========================================================

By making a contribution to the Libgcrypt project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the free software license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the
    best of my knowledge, is covered under an appropriate free
    software license and I have the right under that license to
    submit that work with modifications, whether created in whole
    or in part by me, under the same free software license
    (unless I am permitted to submit under a different license),
    as indicated in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including
    all personal information I submit with it, including my
    sign-off) is maintained indefinitely and may be redistributed
    consistent with this project or the free software license(s)
    involved.

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin at intel.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20121214/07952cbc/attachment.pgp>

From wk at gnupg.org  Fri Dec 14 12:30:32 2012
From: wk at gnupg.org (Werner Koch)
Date: Fri, 14 Dec 2012 12:30:32 +0100
Subject: DCO
In-Reply-To: <50CAE2DB.80302@intel.com> (Dmitry Kasatkin's message of "Fri, 14
	Dec 2012 10:27:07 +0200")
References: <50CAE2DB.80302@intel.com>
Message-ID: <87vcc498h3.fsf@vigenere.g10code.de>

On Fri, 14 Dec 2012 09:27, dmitry.kasatkin at intel.com said:

> Here is my DCO.

Thanks.  Due to the usual Mailman bug, the signaure delivered by Mailman
is broken, but the CC I received was fine.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dmitry.kasatkin at intel.com  Fri Dec 14 12:43:12 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Fri, 14 Dec 2012 13:43:12 +0200
Subject: DCO
In-Reply-To: <87vcc498h3.fsf@vigenere.g10code.de>
References: <50CAE2DB.80302@intel.com>
	<87vcc498h3.fsf@vigenere.g10code.de>
Message-ID: <CALLzPKZ00HQ7J2V6v-_tPfRZr+3tF5QAO83CiMnAHER9B8UtQQ@mail.gmail.com>

>From rndhw.c

Why such strange code is needed?
on i386 unsigned long is always 4...

Where is it different?

- Thanks

#undef USE_PADLOCK
#ifdef ENABLE_PADLOCK_SUPPORT
# ifdef HAVE_GCC_ATTRIBUTE_ALIGNED
#  if (defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4) || defined(__x86_64__)
#   define USE_PADLOCK 1
#  endif
# endif
#endif /*ENABLE_PADLOCK_SUPPORT*/



On Fri, Dec 14, 2012 at 1:30 PM, Werner Koch <wk at gnupg.org> wrote:
> On Fri, 14 Dec 2012 09:27, dmitry.kasatkin at intel.com said:
>
>> Here is my DCO.
>
> Thanks.  Due to the usual Mailman bug, the signaure delivered by Mailman
> is broken, but the CC I received was fine.
>
>
> Shalom-Salam,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>


From wk at gnupg.org  Fri Dec 14 15:48:40 2012
From: wk at gnupg.org (Werner Koch)
Date: Fri, 14 Dec 2012 15:48:40 +0100
Subject: DCO
In-Reply-To: <CALLzPKZ00HQ7J2V6v-_tPfRZr+3tF5QAO83CiMnAHER9B8UtQQ@mail.gmail.com>
	(Dmitry Kasatkin's message of "Fri, 14 Dec 2012 13:43:12 +0200")
References: <50CAE2DB.80302@intel.com> <87vcc498h3.fsf@vigenere.g10code.de>
	<CALLzPKZ00HQ7J2V6v-_tPfRZr+3tF5QAO83CiMnAHER9B8UtQQ@mail.gmail.com>
Message-ID: <87lid08zav.fsf@vigenere.g10code.de>

On Fri, 14 Dec 2012 12:43, dmitry.kasatkin at intel.com said:

> Why such strange code is needed?
> on i386 unsigned long is always 4...

There is no need for it; a different ABI may be in use.  There is no
need that the size of the types correspond with the native sizes of the
CPU.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dmitry.kasatkin at intel.com  Mon Dec 17 14:52:44 2012
From: dmitry.kasatkin at intel.com (Dmitry Kasatkin)
Date: Mon, 17 Dec 2012 15:52:44 +0200
Subject: [PATCH 1/1] Add support for using DRNG random number generator
Message-ID: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>

This patch provides support for using Digital Random Number Generator (DRNG)
engine, which is available on the latest Intel's CPUs. DRNG engine is
accesible via new the RDRAND instruction.

This patch adds the following:
- support for disabling using of rdrand instruction
- checking for RDRAND instruction support using cpuid
- RDRAND usage implementation

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin at intel.com>
---
 configure.ac     |   13 ++++++++++++
 random/rndhw.c   |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/g10lib.h     |    1 +
 src/global.c     |    1 +
 src/hwfeatures.c |   30 +++++++++++++++++++++++++++
 5 files changed, 106 insertions(+)

diff --git a/configure.ac b/configure.ac
index ff07dda..7d162a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -544,6 +544,18 @@ if test x"$aesnisupport" = xyes ; then
             [Enable support for Intel AES-NI instructions.])
 fi
 
+# Implementation of the --disable-drng-support switch.
+AC_MSG_CHECKING([whether DRNG support is requested])
+AC_ARG_ENABLE(drng-support,
+              AC_HELP_STRING([--disable-drng-support],
+                 [Disable support for the Intel DRNG (RDRAND instruction)]),
+	      drngsupport=$enableval,drngsupport=yes)
+AC_MSG_RESULT($drngsupport)
+if test x"$drngsupport" = xyes ; then
+  AC_DEFINE(ENABLE_DRNG_SUPPORT, 1,
+            [Enable support for Intel DRNG (RDRAND instruction).])
+fi
+
 # Implementation of the --disable-O-flag-munging switch.
 AC_MSG_CHECKING([whether a -O flag munging is requested])
 AC_ARG_ENABLE([O-flag-munging],
@@ -1304,6 +1316,7 @@ echo "
         Using linux capabilities:  $use_capabilities
         Try using Padlock crypto:  $padlocksupport
         Try using AES-NI crypto:   $aesnisupport
+        Try using DRNG (RDRAND):   $drngsupport
 "
 
 if test "$print_egd_notice" = "yes"; then
diff --git a/random/rndhw.c b/random/rndhw.c
index 775d90f..08f16cc 100644
--- a/random/rndhw.c
+++ b/random/rndhw.c
@@ -34,6 +34,16 @@
 # endif
 #endif /*ENABLE_PADLOCK_SUPPORT*/
 
+#undef USE_DRNG
+#ifdef ENABLE_DRNG_SUPPORT
+# ifdef __GNUC__
+#  if (defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4) || defined(__x86_64__)
+#   define USE_DRNG 1
+#  endif
+# endif
+#endif /*ENABLE_RDRAND_SUPPORT*/
+
+typedef void (*add_fn_t)(const void*, size_t, enum random_origins);
 
 /* Keep track on whether the RNG has problems.  */
 static volatile int rng_failed;
@@ -108,6 +118,49 @@ poll_padlock (void (*add)(const void*, size_t, enum random_origins),
 }
 #endif /*USE_PADLOCK*/
 
+#ifdef USE_DRNG
+
+#define RDRAND_RETRY_LOOPS	10
+
+#define RDRAND_INT	".byte 0x0f,0xc7,0xf0"
+#ifdef __x86_64__
+# define RDRAND_LONG	".byte 0x48,0x0f,0xc7,0xf0"
+#else
+# define RDRAND_LONG	RDRAND_INT
+#endif
+
+static inline int rdrand_long(unsigned long *v)
+{
+	int ok;
+	asm volatile("1: " RDRAND_LONG "\n\t"
+		     "jc 2f\n\t"
+		     "decl %0\n\t"
+		     "jnz 1b\n\t"
+		     "2:"
+		     : "=r" (ok), "=a" (*v)
+		     : "0" (RDRAND_RETRY_LOOPS));
+	return ok;
+}
+
+static inline int rdrand_nlong(unsigned long *v, int count)
+{
+	while (count--)
+		if (!rdrand_long(v++))
+			return 0;
+	return 1;
+}
+
+static size_t poll_drng(add_fn_t add, enum random_origins origin, int fast)
+{
+	volatile char buffer[64] __attribute__ ((aligned (8)));
+	unsigned int nbytes = sizeof(buffer);
+
+	if (!rdrand_nlong((unsigned long *)buffer, sizeof(buffer)/sizeof(long)))
+		return 0;
+	(*add)((void *)buffer, nbytes, origin);
+	return nbytes;
+}
+#endif /*USE_DRNG*/
 
 int
 _gcry_rndhw_failed_p (void)
@@ -125,6 +178,10 @@ _gcry_rndhw_poll_fast (void (*add)(const void*, size_t, enum random_origins),
   (void)add;
   (void)origin;
 
+#ifdef USE_DRNG
+  if ((_gcry_get_hw_features () & HWF_INTEL_RDRAND))
+    poll_drng (add, origin, 1);
+#endif
 #ifdef USE_PADLOCK
   if ((_gcry_get_hw_features () & HWF_PADLOCK_RNG))
     poll_padlock (add, origin, 1);
@@ -143,6 +200,10 @@ _gcry_rndhw_poll_slow (void (*add)(const void*, size_t, enum random_origins),
   (void)add;
   (void)origin;
 
+#ifdef USE_DRNG
+  if ((_gcry_get_hw_features () & HWF_INTEL_RDRAND))
+    nbytes += poll_drng (add, origin, 0);
+#endif
 #ifdef USE_PADLOCK
   if ((_gcry_get_hw_features () & HWF_PADLOCK_RNG))
     nbytes += poll_padlock (add, origin, 0);
diff --git a/src/g10lib.h b/src/g10lib.h
index f1af399..5e99c46 100644
--- a/src/g10lib.h
+++ b/src/g10lib.h
@@ -151,6 +151,7 @@ int _gcry_log_verbosity( int level );
 #define HWF_PADLOCK_MMUL 8
 
 #define HWF_INTEL_AESNI  256
+#define HWF_INTEL_RDRAND 512
 
 
 unsigned int _gcry_get_hw_features (void);
diff --git a/src/global.c b/src/global.c
index f280a7b..2428e21 100644
--- a/src/global.c
+++ b/src/global.c
@@ -66,6 +66,7 @@ static struct
     { HWF_PADLOCK_SHA, "padlock-sha" },
     { HWF_PADLOCK_MMUL,"padlock-mmul"},
     { HWF_INTEL_AESNI, "intel-aesni" },
+    { HWF_INTEL_RDRAND,"intel-rdrand" },
     { 0, NULL}
   };
 
diff --git a/src/hwfeatures.c b/src/hwfeatures.c
index 82c435b..e55d9b6 100644
--- a/src/hwfeatures.c
+++ b/src/hwfeatures.c
@@ -134,6 +134,20 @@ detect_x86_64_gnuc (void)
      : "%eax", "%ebx", "%ecx", "%edx", "cc"
      );
 #endif /*#ifdef ENABLE_AESNI_SUPPORT*/
+#ifdef ENABLE_DRNG_SUPPORT
+   asm volatile
+     ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
+      "cpuid\n"
+      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
+      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
+      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
+
+      ".Lno_rdrand%=:\n"
+      : "+r" (hw_features)
+      :
+      : "%eax", "%ecx", "%edx", "cc"
+      );
+#endif /* #ifdef ENABLE_DRNG_SUPPORT */
 
 }
 #endif /* __x86_64__ && __GNUC__ */
@@ -267,6 +281,22 @@ detect_ia32_gnuc (void)
      : "%eax", "%ecx", "%edx", "cc"
      );
 #endif /*ENABLE_AESNI_SUPPORT*/
+#ifdef ENABLE_DRNG_SUPPORT
+   asm volatile
+     ("pushl %%ebx\n\t"	        /* Save GOT register.  */
+      "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
+      "cpuid\n"
+      "popl %%ebx\n\t"	        /* Restore GOT register. */
+      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
+      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
+      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
+
+      ".Lno_rdrand%=:\n"
+      : "+r" (hw_features)
+      :
+      : "%eax", "%ecx", "%edx", "cc"
+      );
+#endif /*ENABLE_DRNG_SUPPORT*/
 
 }
 #endif /* __i386__ && SIZEOF_UNSIGNED_LONG == 4 && __GNUC__ */
-- 
1.7.10.4



From jussi.kivilinna at mbnet.fi  Mon Dec 17 16:06:50 2012
From: jussi.kivilinna at mbnet.fi (Jussi Kivilinna)
Date: Mon, 17 Dec 2012 17:06:50 +0200
Subject: [PATCH 1/1] Add support for using DRNG random number generator
In-Reply-To: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>
References: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>
Message-ID: <20121217170650.11563s110xa19t6o@www.dalek.fi>

Quoting Dmitry Kasatkin <dmitry.kasatkin at intel.com>:

> This patch provides support for using Digital Random Number Generator (DRNG)
> engine, which is available on the latest Intel's CPUs. DRNG engine is
> accesible via new the RDRAND instruction.
>
> This patch adds the following:
> - support for disabling using of rdrand instruction
> - checking for RDRAND instruction support using cpuid
> - RDRAND usage implementation
>
> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin at intel.com>
> ---
<snip>
>
> diff --git a/src/hwfeatures.c b/src/hwfeatures.c
> index 82c435b..e55d9b6 100644
> --- a/src/hwfeatures.c
> +++ b/src/hwfeatures.c
> @@ -134,6 +134,20 @@ detect_x86_64_gnuc (void)
>       : "%eax", "%ebx", "%ecx", "%edx", "cc"
>       );
>  #endif /*#ifdef ENABLE_AESNI_SUPPORT*/
> +#ifdef ENABLE_DRNG_SUPPORT
> +   asm volatile
> +     ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
> +      "cpuid\n"
> +      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
> +      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
> +      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
> +
> +      ".Lno_rdrand%=:\n"
> +      : "+r" (hw_features)
> +      :
> +      : "%eax", "%ecx", "%edx", "cc"

%ebx gets modified by cpuid too.

> +      );
> +#endif /* #ifdef ENABLE_DRNG_SUPPORT */
>
>  }
>  #endif /* __x86_64__ && __GNUC__ */
> @@ -267,6 +281,22 @@ detect_ia32_gnuc (void)
>       : "%eax", "%ecx", "%edx", "cc"
>       );
>  #endif /*ENABLE_AESNI_SUPPORT*/
> +#ifdef ENABLE_DRNG_SUPPORT
> +   asm volatile
> +     ("pushl %%ebx\n\t"	        /* Save GOT register.  */
> +      "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
> +      "cpuid\n"
> +      "popl %%ebx\n\t"	        /* Restore GOT register. */
> +      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
> +      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
> +      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
> +
> +      ".Lno_rdrand%=:\n"
> +      : "+r" (hw_features)
> +      :
> +      : "%eax", "%ecx", "%edx", "cc"
> +      );
> +#endif /*ENABLE_DRNG_SUPPORT*/
>
>  }
>  #endif /* __i386__ && SIZEOF_UNSIGNED_LONG == 4 && __GNUC__ */
> --
> 1.7.10.4
>
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
>





From jussi.kivilinna at mbnet.fi  Mon Dec 17 16:24:07 2012
From: jussi.kivilinna at mbnet.fi (Jussi Kivilinna)
Date: Mon, 17 Dec 2012 17:24:07 +0200
Subject: [PATCH 1/1] Add support for using DRNG random number generator
In-Reply-To: <CALLzPKYBdnedUX6G9OobvMf+N+e6iStkTLyVsqr8wKgPi_B=Fw@mail.gmail.com>
References: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>
	<20121217170650.11563s110xa19t6o@www.dalek.fi>
	<CALLzPKYBdnedUX6G9OobvMf+N+e6iStkTLyVsqr8wKgPi_B=Fw@mail.gmail.com>
Message-ID: <20121217172407.70121m7ryqjohxq8@www.dalek.fi>

Quoting "Kasatkin, Dmitry" <dmitry.kasatkin at intel.com>:

> On Mon, Dec 17, 2012 at 5:06 PM, Jussi Kivilinna
> <jussi.kivilinna at mbnet.fi> wrote:
>> Quoting Dmitry Kasatkin <dmitry.kasatkin at intel.com>:
>>
>>> This patch provides support for using Digital Random Number Generator
>>> (DRNG)
>>> engine, which is available on the latest Intel's CPUs. DRNG engine is
>>> accesible via new the RDRAND instruction.
>>>
>>> This patch adds the following:
>>> - support for disabling using of rdrand instruction
>>> - checking for RDRAND instruction support using cpuid
>>> - RDRAND usage implementation
>>>
>>> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin at intel.com>
>>> ---
>>
>> <snip>
>>
>>>
>>> diff --git a/src/hwfeatures.c b/src/hwfeatures.c
>>> index 82c435b..e55d9b6 100644
>>> --- a/src/hwfeatures.c
>>> +++ b/src/hwfeatures.c
>>> @@ -134,6 +134,20 @@ detect_x86_64_gnuc (void)
>>>       : "%eax", "%ebx", "%ecx", "%edx", "cc"
>>>       );
>>>  #endif /*#ifdef ENABLE_AESNI_SUPPORT*/
>>> +#ifdef ENABLE_DRNG_SUPPORT
>>> +   asm volatile
>>> +     ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.
>>> */
>>> +      "cpuid\n"
>>> +      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
>>> +      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
>>> +      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
>>> +
>>> +      ".Lno_rdrand%=:\n"
>>> +      : "+r" (hw_features)
>>> +      :
>>> +      : "%eax", "%ecx", "%edx", "cc"
>>
>>
>> %ebx gets modified by cpuid too.
>>
>
> Indeed...
>
> But seems not on 32 bit architecture.

On 32bit, %ebx is currently manually stored/restored through stack.  
Probably clobbering %ebx would be enough there too and gcc would  
handle this automatically. IMHO, hwfeatures.c needs some clean-up,  
moving cpuid assembler to separate function and handling flag checking  
in C instead of asm.

>
>>> +      );
>>> +#endif /* #ifdef ENABLE_DRNG_SUPPORT */
>>>
>>>  }
>>>  #endif /* __x86_64__ && __GNUC__ */
>>> @@ -267,6 +281,22 @@ detect_ia32_gnuc (void)
>>>       : "%eax", "%ecx", "%edx", "cc"
>>>       );
>>>  #endif /*ENABLE_AESNI_SUPPORT*/
>>> +#ifdef ENABLE_DRNG_SUPPORT
>>> +   asm volatile
>>> +     ("pushl %%ebx\n\t"                /* Save GOT register.  */
>>> +      "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.
>>> */
>>> +      "cpuid\n"
>>> +      "popl %%ebx\n\t"         /* Restore GOT register. */
>>> +      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
>>> +      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
>>> +      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
>>> +
>>> +      ".Lno_rdrand%=:\n"
>>> +      : "+r" (hw_features)
>>> +      :
>>> +      : "%eax", "%ecx", "%edx", "cc"
>>> +      );
>>> +#endif /*ENABLE_DRNG_SUPPORT*/
>>>
>>>  }
>>>  #endif /* __i386__ && SIZEOF_UNSIGNED_LONG == 4 && __GNUC__ */
>>> --
>>> 1.7.10.4
>>>
>>>
>>> _______________________________________________
>>> Gcrypt-devel mailing list
>>> Gcrypt-devel at gnupg.org
>>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>>>
>>>
>>
>>
>>
>
>





From dmitry.kasatkin at intel.com  Mon Dec 17 16:11:45 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Mon, 17 Dec 2012 17:11:45 +0200
Subject: [PATCH 1/1] Add support for using DRNG random number generator
In-Reply-To: <20121217170650.11563s110xa19t6o@www.dalek.fi>
References: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>
	<20121217170650.11563s110xa19t6o@www.dalek.fi>
Message-ID: <CALLzPKYBdnedUX6G9OobvMf+N+e6iStkTLyVsqr8wKgPi_B=Fw@mail.gmail.com>

On Mon, Dec 17, 2012 at 5:06 PM, Jussi Kivilinna
<jussi.kivilinna at mbnet.fi> wrote:
> Quoting Dmitry Kasatkin <dmitry.kasatkin at intel.com>:
>
>> This patch provides support for using Digital Random Number Generator
>> (DRNG)
>> engine, which is available on the latest Intel's CPUs. DRNG engine is
>> accesible via new the RDRAND instruction.
>>
>> This patch adds the following:
>> - support for disabling using of rdrand instruction
>> - checking for RDRAND instruction support using cpuid
>> - RDRAND usage implementation
>>
>> Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin at intel.com>
>> ---
>
> <snip>
>
>>
>> diff --git a/src/hwfeatures.c b/src/hwfeatures.c
>> index 82c435b..e55d9b6 100644
>> --- a/src/hwfeatures.c
>> +++ b/src/hwfeatures.c
>> @@ -134,6 +134,20 @@ detect_x86_64_gnuc (void)
>>       : "%eax", "%ebx", "%ecx", "%edx", "cc"
>>       );
>>  #endif /*#ifdef ENABLE_AESNI_SUPPORT*/
>> +#ifdef ENABLE_DRNG_SUPPORT
>> +   asm volatile
>> +     ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.
>> */
>> +      "cpuid\n"
>> +      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
>> +      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
>> +      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
>> +
>> +      ".Lno_rdrand%=:\n"
>> +      : "+r" (hw_features)
>> +      :
>> +      : "%eax", "%ecx", "%edx", "cc"
>
>
> %ebx gets modified by cpuid too.
>

Indeed...

But seems not on 32 bit architecture.

>> +      );
>> +#endif /* #ifdef ENABLE_DRNG_SUPPORT */
>>
>>  }
>>  #endif /* __x86_64__ && __GNUC__ */
>> @@ -267,6 +281,22 @@ detect_ia32_gnuc (void)
>>       : "%eax", "%ecx", "%edx", "cc"
>>       );
>>  #endif /*ENABLE_AESNI_SUPPORT*/
>> +#ifdef ENABLE_DRNG_SUPPORT
>> +   asm volatile
>> +     ("pushl %%ebx\n\t"                /* Save GOT register.  */
>> +      "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.
>> */
>> +      "cpuid\n"
>> +      "popl %%ebx\n\t"         /* Restore GOT register. */
>> +      "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
>> +      "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
>> +      "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
>> +
>> +      ".Lno_rdrand%=:\n"
>> +      : "+r" (hw_features)
>> +      :
>> +      : "%eax", "%ecx", "%edx", "cc"
>> +      );
>> +#endif /*ENABLE_DRNG_SUPPORT*/
>>
>>  }
>>  #endif /* __i386__ && SIZEOF_UNSIGNED_LONG == 4 && __GNUC__ */
>> --
>> 1.7.10.4
>>
>>
>> _______________________________________________
>> Gcrypt-devel mailing list
>> Gcrypt-devel at gnupg.org
>> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>>
>>
>
>
>


From wk at gnupg.org  Tue Dec 18 09:42:20 2012
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Dec 2012 09:42:20 +0100
Subject: [PATCH 1/1] Add support for using DRNG random number generator
In-Reply-To: <20121217172407.70121m7ryqjohxq8@www.dalek.fi> (Jussi Kivilinna's
	message of "Mon, 17 Dec 2012 17:24:07 +0200")
References: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>
	<20121217170650.11563s110xa19t6o@www.dalek.fi>
	<CALLzPKYBdnedUX6G9OobvMf+N+e6iStkTLyVsqr8wKgPi_B=Fw@mail.gmail.com>
	<20121217172407.70121m7ryqjohxq8@www.dalek.fi>
Message-ID: <874njj4uqb.fsf@vigenere.g10code.de>

On Mon, 17 Dec 2012 16:24, jussi.kivilinna at mbnet.fi said:

> handle this automatically. IMHO, hwfeatures.c needs some clean-up,
> moving cpuid assembler to separate function and handling flag checking
> in C instead of asm.

I can see that this makes sense.  In particular if we assume that we may
support more features in the future.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From wk at gnupg.org  Tue Dec 18 10:41:30 2012
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Dec 2012 10:41:30 +0100
Subject: thread-safety when used by a library
In-Reply-To: <CAJU7zaKO0sC+dWtc0FY--him3H=nre29ABhxZkrPiPyFTwziZw@mail.gmail.com>
	(Nikos Mavrogiannopoulos's message of "Thu, 13 Dec 2012 16:29:27
	+0100")
References: <CAATLsPaeU_1pXZw-juOrUqUMuXX+WmBcVcrimE1A+VZeaz2rGw@mail.gmail.com>
	<87obhyb5pj.fsf@vigenere.g10code.de>
	<CAJU7zaKO0sC+dWtc0FY--him3H=nre29ABhxZkrPiPyFTwziZw@mail.gmail.com>
Message-ID: <87k3sf3df9.fsf@vigenere.g10code.de>

On Thu, 13 Dec 2012 16:29, nmav at gnutls.org said:

> to semaphore. Since you don't care about locks across processes having
> semaphores would not provide any advantage, and I'd expect also

The advantage is that semaphores are async-signal-safe, have no owner,
and have proper fork semantics.

> mutexes to be more efficient in threads than semaphores. We use

Marcus did some tests before he used a semaphore in nPth and cam to the
conclusion that there is no performance penalty compared to a mutex.

> About the the issues with fork and pthreads, I think they cannot be
> solved by a library and users who mix them should figure a proper
> initialization sequence anyway. Applications that do that maybe should
> be allowed to register their own locks they can control (I don't think

You are still trapped by all the Posix mutex peculiarities.  In
particular, an application may not know which library it uses and thus
it would be better for the library to be free of all possible problems.

I will do some more tests, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From jussi.kivilinna at mbnet.fi  Tue Dec 18 11:16:22 2012
From: jussi.kivilinna at mbnet.fi (Jussi Kivilinna)
Date: Tue, 18 Dec 2012 12:16:22 +0200
Subject: [PATCH 1/1] Add support for using DRNG random number generator
In-Reply-To: <874njj4uqb.fsf@vigenere.g10code.de>
References: <bcf7e43c73b8e644c3665a44d7335b57ca404add.1355752318.git.dmitry.kasatkin@intel.com>
	<20121217170650.11563s110xa19t6o@www.dalek.fi>
	<CALLzPKYBdnedUX6G9OobvMf+N+e6iStkTLyVsqr8wKgPi_B=Fw@mail.gmail.com>
	<20121217172407.70121m7ryqjohxq8@www.dalek.fi>
	<874njj4uqb.fsf@vigenere.g10code.de>
Message-ID: <20121218121622.19031v2xex6lofog@www.dalek.fi>

Quoting Werner Koch <wk at gnupg.org>:

> On Mon, 17 Dec 2012 16:24, jussi.kivilinna at mbnet.fi said:
>
>> handle this automatically. IMHO, hwfeatures.c needs some clean-up,
>> moving cpuid assembler to separate function and handling flag checking
>> in C instead of asm.
>
> I can see that this makes sense.  In particular if we assume that we may
> support more features in the future.

This would also allow same main x86-64/i386 features function to be  
used, with i386/x86-64 specific asm functions in get_cpuid() and  
is_cpuid_available().

I can do this, only problem being that I don't have access to device  
with VIA CPU to (easily) verify padlock parts.

-Jussi

>
>
> Salam-Shalom,
>
>    Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>
>
>





From dmitry.kasatkin at intel.com  Tue Dec 18 13:56:48 2012
From: dmitry.kasatkin at intel.com (Dmitry Kasatkin)
Date: Tue, 18 Dec 2012 14:56:48 +0200
Subject: [PATCHv2 1/1] Add support for using DRNG random number generator
Message-ID: <d2748ea1706319dbbb92cfb25df5d2500f0211bb.1355835397.git.dmitry.kasatkin@intel.com>

This patch provides support for using Digital Random Number Generator (DRNG)
engine, which is available on the latest Intel's CPUs. DRNG engine is
accesible via new the RDRAND instruction.

This patch adds the following:
- support for disabling using of rdrand instruction
- checking for RDRAND instruction support using cpuid
- RDRAND usage implementation

Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin at intel.com>
---
 configure.ac     |   13 ++++++++++++
 random/rndhw.c   |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 src/g10lib.h     |    1 +
 src/global.c     |    1 +
 src/hwfeatures.c |   30 +++++++++++++++++++++++++++
 5 files changed, 106 insertions(+)

diff --git a/configure.ac b/configure.ac
index ff07dda..7d162a2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -544,6 +544,18 @@ if test x"$aesnisupport" = xyes ; then
             [Enable support for Intel AES-NI instructions.])
 fi
 
+# Implementation of the --disable-drng-support switch.
+AC_MSG_CHECKING([whether DRNG support is requested])
+AC_ARG_ENABLE(drng-support,
+              AC_HELP_STRING([--disable-drng-support],
+                 [Disable support for the Intel DRNG (RDRAND instruction)]),
+	      drngsupport=$enableval,drngsupport=yes)
+AC_MSG_RESULT($drngsupport)
+if test x"$drngsupport" = xyes ; then
+  AC_DEFINE(ENABLE_DRNG_SUPPORT, 1,
+            [Enable support for Intel DRNG (RDRAND instruction).])
+fi
+
 # Implementation of the --disable-O-flag-munging switch.
 AC_MSG_CHECKING([whether a -O flag munging is requested])
 AC_ARG_ENABLE([O-flag-munging],
@@ -1304,6 +1316,7 @@ echo "
         Using linux capabilities:  $use_capabilities
         Try using Padlock crypto:  $padlocksupport
         Try using AES-NI crypto:   $aesnisupport
+        Try using DRNG (RDRAND):   $drngsupport
 "
 
 if test "$print_egd_notice" = "yes"; then
diff --git a/random/rndhw.c b/random/rndhw.c
index 775d90f..08f16cc 100644
--- a/random/rndhw.c
+++ b/random/rndhw.c
@@ -34,6 +34,16 @@
 # endif
 #endif /*ENABLE_PADLOCK_SUPPORT*/
 
+#undef USE_DRNG
+#ifdef ENABLE_DRNG_SUPPORT
+# ifdef __GNUC__
+#  if (defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4) || defined(__x86_64__)
+#   define USE_DRNG 1
+#  endif
+# endif
+#endif /*ENABLE_RDRAND_SUPPORT*/
+
+typedef void (*add_fn_t)(const void*, size_t, enum random_origins);
 
 /* Keep track on whether the RNG has problems.  */
 static volatile int rng_failed;
@@ -108,6 +118,49 @@ poll_padlock (void (*add)(const void*, size_t, enum random_origins),
 }
 #endif /*USE_PADLOCK*/
 
+#ifdef USE_DRNG
+
+#define RDRAND_RETRY_LOOPS	10
+
+#define RDRAND_INT	".byte 0x0f,0xc7,0xf0"
+#ifdef __x86_64__
+# define RDRAND_LONG	".byte 0x48,0x0f,0xc7,0xf0"
+#else
+# define RDRAND_LONG	RDRAND_INT
+#endif
+
+static inline int rdrand_long(unsigned long *v)
+{
+	int ok;
+	asm volatile("1: " RDRAND_LONG "\n\t"
+		     "jc 2f\n\t"
+		     "decl %0\n\t"
+		     "jnz 1b\n\t"
+		     "2:"
+		     : "=r" (ok), "=a" (*v)
+		     : "0" (RDRAND_RETRY_LOOPS));
+	return ok;
+}
+
+static inline int rdrand_nlong(unsigned long *v, int count)
+{
+	while (count--)
+		if (!rdrand_long(v++))
+			return 0;
+	return 1;
+}
+
+static size_t poll_drng(add_fn_t add, enum random_origins origin, int fast)
+{
+	volatile char buffer[64] __attribute__ ((aligned (8)));
+	unsigned int nbytes = sizeof(buffer);
+
+	if (!rdrand_nlong((unsigned long *)buffer, sizeof(buffer)/sizeof(long)))
+		return 0;
+	(*add)((void *)buffer, nbytes, origin);
+	return nbytes;
+}
+#endif /*USE_DRNG*/
 
 int
 _gcry_rndhw_failed_p (void)
@@ -125,6 +178,10 @@ _gcry_rndhw_poll_fast (void (*add)(const void*, size_t, enum random_origins),
   (void)add;
   (void)origin;
 
+#ifdef USE_DRNG
+  if ((_gcry_get_hw_features () & HWF_INTEL_RDRAND))
+    poll_drng (add, origin, 1);
+#endif
 #ifdef USE_PADLOCK
   if ((_gcry_get_hw_features () & HWF_PADLOCK_RNG))
     poll_padlock (add, origin, 1);
@@ -143,6 +200,10 @@ _gcry_rndhw_poll_slow (void (*add)(const void*, size_t, enum random_origins),
   (void)add;
   (void)origin;
 
+#ifdef USE_DRNG
+  if ((_gcry_get_hw_features () & HWF_INTEL_RDRAND))
+    nbytes += poll_drng (add, origin, 0);
+#endif
 #ifdef USE_PADLOCK
   if ((_gcry_get_hw_features () & HWF_PADLOCK_RNG))
     nbytes += poll_padlock (add, origin, 0);
diff --git a/src/g10lib.h b/src/g10lib.h
index f1af399..5e99c46 100644
--- a/src/g10lib.h
+++ b/src/g10lib.h
@@ -151,6 +151,7 @@ int _gcry_log_verbosity( int level );
 #define HWF_PADLOCK_MMUL 8
 
 #define HWF_INTEL_AESNI  256
+#define HWF_INTEL_RDRAND 512
 
 
 unsigned int _gcry_get_hw_features (void);
diff --git a/src/global.c b/src/global.c
index f280a7b..2428e21 100644
--- a/src/global.c
+++ b/src/global.c
@@ -66,6 +66,7 @@ static struct
     { HWF_PADLOCK_SHA, "padlock-sha" },
     { HWF_PADLOCK_MMUL,"padlock-mmul"},
     { HWF_INTEL_AESNI, "intel-aesni" },
+    { HWF_INTEL_RDRAND,"intel-rdrand" },
     { 0, NULL}
   };
 
diff --git a/src/hwfeatures.c b/src/hwfeatures.c
index 82c435b..e89c825 100644
--- a/src/hwfeatures.c
+++ b/src/hwfeatures.c
@@ -134,6 +134,20 @@ detect_x86_64_gnuc (void)
      : "%eax", "%ebx", "%ecx", "%edx", "cc"
      );
 #endif /*#ifdef ENABLE_AESNI_SUPPORT*/
+#ifdef ENABLE_DRNG_SUPPORT
+  asm volatile
+    ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
+     "cpuid\n"
+     "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
+     "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
+     "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
+
+     ".Lno_rdrand%=:\n"
+     : "+r" (hw_features)
+     :
+     : "%eax", "%ebx", "%ecx", "%edx", "cc"
+     );
+#endif /* #ifdef ENABLE_DRNG_SUPPORT */
 
 }
 #endif /* __x86_64__ && __GNUC__ */
@@ -267,6 +281,22 @@ detect_ia32_gnuc (void)
      : "%eax", "%ecx", "%edx", "cc"
      );
 #endif /*ENABLE_AESNI_SUPPORT*/
+#ifdef ENABLE_DRNG_SUPPORT
+  asm volatile
+    ("pushl %%ebx\n\t"	        /* Save GOT register.  */
+     "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
+     "cpuid\n"
+     "popl %%ebx\n\t"	        /* Restore GOT register. */
+     "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
+     "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
+     "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
+
+     ".Lno_rdrand%=:\n"
+     : "+r" (hw_features)
+     :
+     : "%eax", "%ecx", "%edx", "cc"
+     );
+#endif /*ENABLE_DRNG_SUPPORT*/
 
 }
 #endif /* __i386__ && SIZEOF_UNSIGNED_LONG == 4 && __GNUC__ */
-- 
1.7.10.4



From wk at gnupg.org  Tue Dec 18 19:37:37 2012
From: wk at gnupg.org (Werner Koch)
Date: Tue, 18 Dec 2012 19:37:37 +0100
Subject: [PATCHv2 1/1] Add support for using DRNG random number generator
In-Reply-To: <d2748ea1706319dbbb92cfb25df5d2500f0211bb.1355835397.git.dmitry.kasatkin@intel.com>
	(Dmitry Kasatkin's message of "Tue, 18 Dec 2012 14:56:48 +0200")
References: <d2748ea1706319dbbb92cfb25df5d2500f0211bb.1355835397.git.dmitry.kasatkin@intel.com>
Message-ID: <878v8v1a1a.fsf@vigenere.g10code.de>

On Tue, 18 Dec 2012 13:56, dmitry.kasatkin at intel.com said:
> This patch provides support for using Digital Random Number Generator (DRNG)
> engine, which is available on the latest Intel's CPUs. DRNG engine is
> accesible via new the RDRAND instruction.

Pushed.  I added an ChangeLog entry, did some indentation fixes, and
used HAVE_GCC_ATTRIBUTE_ALIGNED instead of __GNUC__.

Thanks,

  Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dmitry.kasatkin at intel.com  Wed Dec 19 08:27:08 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Wed, 19 Dec 2012 09:27:08 +0200
Subject: Delivery test
Message-ID: <CALLzPKYnYWVNibMVtmZ=wyp2QXkDUEg6cpex_Z6LMBqqOvX-qQ@mail.gmail.com>

Hello,

Sorry for spamming.
I test delivery, because I have problems with that.

Thanks,
Dmitry


From dmitry.kasatkin at intel.com  Wed Dec 19 08:33:16 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Wed, 19 Dec 2012 09:33:16 +0200
Subject: Delivery test 2
Message-ID: <CALLzPKaG04YuqBNdtUfKKK-GACXWYRXU247NjZvYsqdeEcB0gA@mail.gmail.com>

Delivery test 2.


From dmitry.kasatkin at intel.com  Wed Dec 19 08:49:13 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Wed, 19 Dec 2012 09:49:13 +0200
Subject: Problems with delivery
Message-ID: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>

Hello,

Does anyone receive posts to this mailing lists?

- Dmitry


From jussi.kivilinna at mbnet.fi  Wed Dec 19 11:09:18 2012
From: jussi.kivilinna at mbnet.fi (Jussi Kivilinna)
Date: Wed, 19 Dec 2012 12:09:18 +0200
Subject: Problems with delivery
In-Reply-To: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>
References: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>
Message-ID: <20121219120918.21447aqzrz5a74sg@www.dalek.fi>

Quoting "Kasatkin, Dmitry" <dmitry.kasatkin at intel.com>:

> Hello,
>
> Does anyone receive posts to this mailing lists?

Maybe you have noticed same problem that I have.. this mailing list  
does not appear to send messages back to address where message came  
from.

-Jussi

>
> - Dmitry
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>
>





From philip-gcrypt at shadowmagic.org.uk  Wed Dec 19 10:28:32 2012
From: philip-gcrypt at shadowmagic.org.uk (Philip Kendall)
Date: Wed, 19 Dec 2012 09:28:32 +0000
Subject: Problems with delivery
In-Reply-To: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>
References: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>
Message-ID: <20121219092832.GO12549@sphinx.mythic-beasts.com>

On Wed, Dec 19, 2012 at 09:49:13AM +0200, Kasatkin, Dmitry wrote:
> 
> Does anyone receive posts to this mailing lists?

Yes :-)

Cheers,

Phil

-- 
  Philip Kendall <philip at shadowmagic.org.uk>
  http://www.shadowmagic.org.uk/


From dmitry.kasatkin at intel.com  Wed Dec 19 11:55:04 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Wed, 19 Dec 2012 12:55:04 +0200
Subject: Problems with delivery
In-Reply-To: <20121219092832.GO12549@sphinx.mythic-beasts.com>
References: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>
	<20121219092832.GO12549@sphinx.mythic-beasts.com>
Message-ID: <CALLzPKbsC-wc_UXq+pwCKi7RX-yU0=GGSJ56aS_H5O1rNZvRZw@mail.gmail.com>

Hello,

This came from ML. It seems I have receive it.
Thanks to all for replies. No more replies are needed :)

- Dmitry


On Wed, Dec 19, 2012 at 11:28 AM, Philip Kendall
<philip-gcrypt at shadowmagic.org.uk> wrote:
> On Wed, Dec 19, 2012 at 09:49:13AM +0200, Kasatkin, Dmitry wrote:
>>
>> Does anyone receive posts to this mailing lists?
>
> Yes :-)
>
> Cheers,
>
> Phil
>
> --
>   Philip Kendall <philip at shadowmagic.org.uk>
>   http://www.shadowmagic.org.uk/
>
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel


From wk at gnupg.org  Wed Dec 19 13:35:10 2012
From: wk at gnupg.org (Werner Koch)
Date: Wed, 19 Dec 2012 13:35:10 +0100
Subject: Problems with delivery
In-Reply-To: <20121219120918.21447aqzrz5a74sg@www.dalek.fi> (Jussi Kivilinna's
	message of "Wed, 19 Dec 2012 12:09:18 +0200")
References: <CALLzPKbXYQYBU6PUq79PUGxsNNosSXCpOo9ZmoYarA3aYBaHzA@mail.gmail.com>
	<20121219120918.21447aqzrz5a74sg@www.dalek.fi>
Message-ID: <87sj72xls1.fsf@vigenere.g10code.de>

On Wed, 19 Dec 2012 11:09, jussi.kivilinna at mbnet.fi said:

> Maybe you have noticed same problem that I have.. this mailing list
> does not appear to send messages back to address where message came
> from.

Right.  The MX for this mailing lists is kerckhoffs.g10code.com, which
does greylisting on the posts and forwards the mails to
trithemius.gnupg.org where the Mailman instance is running.  You receive
all mails from the latter.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.



From dmitry.kasatkin at intel.com  Thu Dec 20 12:51:30 2012
From: dmitry.kasatkin at intel.com (Kasatkin, Dmitry)
Date: Thu, 20 Dec 2012 13:51:30 +0200
Subject: [PATCHv2 1/1] Add support for using DRNG random number generator
In-Reply-To: <878v8v1a1a.fsf@vigenere.g10code.de>
References: <d2748ea1706319dbbb92cfb25df5d2500f0211bb.1355835397.git.dmitry.kasatkin@intel.com>
	<878v8v1a1a.fsf@vigenere.g10code.de>
Message-ID: <CALLzPKYo_MTT1gCRbdMofDLH9Dk3HrwqypeifMKKw3zCxLR0Mg@mail.gmail.com>

Yes.. I have noticed changes.

Thanks.


On Tue, Dec 18, 2012 at 8:37 PM, Werner Koch <wk at gnupg.org> wrote:
> On Tue, 18 Dec 2012 13:56, dmitry.kasatkin at intel.com said:
>> This patch provides support for using Digital Random Number Generator (DRNG)
>> engine, which is available on the latest Intel's CPUs. DRNG engine is
>> accesible via new the RDRAND instruction.
>
> Pushed.  I added an ChangeLog entry, did some indentation fixes, and
> used HAVE_GCC_ATTRIBUTE_ALIGNED instead of __GNUC__.
>
> Thanks,
>
>   Werner
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
>


From jussi.kivilinna at mbnet.fi  Thu Dec 20 14:46:57 2012
From: jussi.kivilinna at mbnet.fi (Jussi Kivilinna)
Date: Thu, 20 Dec 2012 15:46:57 +0200
Subject: [PATCH] Clean up i386/x86-64 cpuid usage in hwfeatures.c
Message-ID: <20121220134657.2475.32324.stgit@localhost6.localdomain6>

* src/hwfeatures.c [__i386__ && __GNUC__] (detect_ia32_gnuc): Remove.
[__x86_64__ && __GNUC__] (detect_x86_64_gnuc): Remove.
[__i386__ && __GNUC__] (is_cpuid_available, get_cpuid)
(HAS_X86_CPUID): New.
[__x86_64__ && __GNUC__] (is_cpuid_available, get_cpuid)
(HAS_X86_CPUID): New.
[HAS_X86_CPUID] (detect_x86_gnuc): New.
(_gcry_detect_hw_features) [__i386__ && GNUC]: Remove detect_ia32_gnuc
call.
(_gcry_detect_hw_features) [__x86_64__ && GNUC]: Remove
detect_x86_64_gnuc call.
(_gcry_detect_hw_features) [HAS_X86_CPUID]: Add detect_x86_gnuc call.
--

For hwfeatures.c clean up, merge i386/x86-64 hardware detection and move
i386/x86-64 spesific assembler to separate functions, is_cpuid_available() and
get_cpuid().

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at mbnet.fi>
---
 src/hwfeatures.c |  340 +++++++++++++++++++-----------------------------------
 1 file changed, 122 insertions(+), 218 deletions(-)

diff --git a/src/hwfeatures.c b/src/hwfeatures.c
index e89c825..62600aa 100644
--- a/src/hwfeatures.c
+++ b/src/hwfeatures.c
@@ -40,126 +40,15 @@ _gcry_get_hw_features (void)
 }
 
 
-#if defined (__x86_64__) && defined (__GNUC__)
-static void
-detect_x86_64_gnuc (void)
-{
-  /* The code here is only useful for the PadLock engine thus we don't
-     build it if that support has been disabled.  */
-  char vendor_id[12+1];
-
-  asm volatile
-    ("xorl  %%eax, %%eax\n\t"    /* 0 -> EAX.  */
-     "cpuid\n\t"                 /* Get vendor ID.  */
-     "movl  %%ebx, (%0)\n\t"     /* EBX,EDX,ECX -> VENDOR_ID.  */
-     "movl  %%edx, 4(%0)\n\t"
-     "movl  %%ecx, 8(%0)\n\t"
-     :
-     : "S" (&vendor_id[0])
-     : "%eax", "%ebx", "%ecx", "%edx", "cc"
-     );
-  vendor_id[12] = 0;
-
-  if (0)
-    ; /* Just to make "else if" and ifdef macros look pretty.  */
-#ifdef ENABLE_PADLOCK_SUPPORT
-  else if (!strcmp (vendor_id, "CentaurHauls"))
-    {
-      /* This is a VIA CPU.  Check what PadLock features we have.  */
-      asm volatile
-        ("movl $0xC0000000, %%eax\n\t"  /* Check for extended centaur  */
-         "cpuid\n\t"                    /* feature flags.              */
-         "cmpl $0xC0000001, %%eax\n\t"
-         "jb .Lready%=\n\t"             /* EAX < 0xC0000000 => no padlock.  */
-
-         "movl $0xC0000001, %%eax\n\t"  /* Ask for the extended */
-         "cpuid\n\t"                    /* feature flags.       */
-
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0x0C, %%eax\n\t"        /* Test bits 2 and 3 to see whether */
-         "cmpl $0x0C, %%eax\n\t"        /* the RNG exists and is enabled.   */
-         "jnz .Lno_rng%=\n\t"
-         "orl $1, %0\n"                 /* Set our HWF_PADLOCK_RNG bit.  */
-
-         ".Lno_rng%=:\n\t"
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0xC0, %%eax\n\t"        /* Test bits 6 and 7 to see whether */
-         "cmpl $0xC0, %%eax\n\t"        /* the ACE exists and is enabled.   */
-         "jnz .Lno_ace%=\n\t"
-         "orl $2, %0\n"                 /* Set our HWF_PADLOCK_AES bit.  */
-
-         ".Lno_ace%=:\n\t"
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0xC00, %%eax\n\t"       /* Test bits 10, 11 to see whether  */
-         "cmpl $0xC00, %%eax\n\t"       /* the PHE exists and is enabled.   */
-         "jnz .Lno_phe%=\n\t"
-         "orl $4, %0\n"                 /* Set our HWF_PADLOCK_SHA bit.  */
-
-         ".Lno_phe%=:\n\t"
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0x3000, %%eax\n\t"      /* Test bits 12, 13 to see whether  */
-         "cmpl $0x3000, %%eax\n\t"      /* MONTMUL exists and is enabled.   */
-         "jnz .Lready%=\n\t"
-         "orl $8, %0\n"                 /* Set our HWF_PADLOCK_MMUL bit.  */
-
-         ".Lready%=:\n"
-         : "+r" (hw_features)
-         :
-         : "%eax", "%ebx", "%ecx", "%edx", "cc"
-         );
-    }
-#endif /*ENABLE_PADLOCK_SUPPORT*/
-  else if (!strcmp (vendor_id, "GenuineIntel"))
-    {
-      /* This is an Intel CPU.  */
-    }
-  else if (!strcmp (vendor_id, "AuthenticAMD"))
-    {
-      /* This is an AMD CPU.  */
-    }
-
-  /* Detect Intel features, that might also be supported by other
-     vendors.  */
-#ifdef ENABLE_AESNI_SUPPORT
-  asm volatile
-    ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
-     "cpuid\n"
-     "testl $0x02000000, %%ecx\n\t" /* Test bit 25.  */
-     "jz .Lno_aes%=\n\t"            /* No AES support.  */
-     "orl $256, %0\n"               /* Set our HWF_INTEL_AES bit.  */
-
-     ".Lno_aes%=:\n"
-     : "+r" (hw_features)
-     :
-     : "%eax", "%ebx", "%ecx", "%edx", "cc"
-     );
-#endif /*#ifdef ENABLE_AESNI_SUPPORT*/
-#ifdef ENABLE_DRNG_SUPPORT
-  asm volatile
-    ("movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
-     "cpuid\n"
-     "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
-     "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
-     "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
-
-     ".Lno_rdrand%=:\n"
-     : "+r" (hw_features)
-     :
-     : "%eax", "%ebx", "%ecx", "%edx", "cc"
-     );
-#endif /* #ifdef ENABLE_DRNG_SUPPORT */
-
-}
-#endif /* __x86_64__ && __GNUC__ */
+#undef HAS_X86_CPUID
 
 #if defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4 && defined (__GNUC__)
-static void
-detect_ia32_gnuc (void)
+#define HAS_X86_CPUID 1
+
+static int
+is_cpuid_available(void)
 {
-  /* The code here is only useful for the PadLock engine thus we don't
-     build it if that support has been disabled.  */
   int has_cpuid = 0;
-  char vendor_id[12+1];
 
   /* Detect the CPUID feature by testing some undefined behaviour (16
      vs 32 bit pushf/popf). */
@@ -183,21 +72,85 @@ detect_ia32_gnuc (void)
      : "%eax", "%ecx", "cc"
      );
 
-  if (!has_cpuid)
-    return;  /* No way.  */
+  return has_cpuid;
+}
+
+static void
+get_cpuid(unsigned int in, unsigned int *eax, unsigned int *ebx,
+          unsigned int *ecx, unsigned int *edx)
+{
+  unsigned int regs[4];
 
   asm volatile
     ("pushl %%ebx\n\t"           /* Save GOT register.  */
-     "xorl  %%eax, %%eax\n\t"    /* 0 -> EAX.  */
-     "cpuid\n\t"                 /* Get vendor ID.  */
-     "movl  %%ebx, (%0)\n\t"     /* EBX,EDX,ECX -> VENDOR_ID.  */
-     "movl  %%edx, 4(%0)\n\t"
-     "movl  %%ecx, 8(%0)\n\t"
-     "popl  %%ebx\n"
-     :
-     : "S" (&vendor_id[0])
-     : "%eax", "%ecx", "%edx", "cc"
+     "cpuid\n\t"
+     "movl %%ebx, %1\n\t"
+     "popl %%ebx\n\t"            /* Restore GOT register. */
+     : "=a" (regs[0]), "=r" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
+     : "0" (in)
+     : "cc"
      );
+
+  if (eax)
+    *eax = regs[0];
+  if (ebx)
+    *ebx = regs[1];
+  if (ecx)
+    *ecx = regs[2];
+  if (edx)
+    *edx = regs[3];
+}
+#endif /* i386 && GNUC */
+
+
+#if defined (__x86_64__) && defined (__GNUC__)
+#define HAS_X86_CPUID 1
+
+static int
+is_cpuid_available(void)
+{
+  return 1;
+}
+
+static void
+get_cpuid(unsigned int in, unsigned int *eax, unsigned int *ebx,
+          unsigned int *ecx, unsigned int *edx)
+{
+  unsigned int regs[4];
+
+  asm volatile
+    ("cpuid\n\t"
+     : "=a" (regs[0]), "=b" (regs[1]), "=c" (regs[2]), "=d" (regs[3])
+     : "0" (in)
+     : "cc"
+     );
+
+  if (eax)
+    *eax = regs[0];
+  if (ebx)
+    *ebx = regs[1];
+  if (ecx)
+    *ecx = regs[2];
+  if (edx)
+    *edx = regs[3];
+}
+#endif /* x86-64 && GNUC */
+
+
+#ifdef HAS_X86_CPUID
+static void
+detect_x86_gnuc (void)
+{
+  char vendor_id[12+1];
+  unsigned int features;
+
+  if (!is_cpuid_available())
+    return;
+
+  get_cpuid(0, NULL,
+            (unsigned int *)&vendor_id[0],
+            (unsigned int *)&vendor_id[8],
+            (unsigned int *)&vendor_id[4]);
   vendor_id[12] = 0;
 
   if (0)
@@ -206,51 +159,34 @@ detect_ia32_gnuc (void)
   else if (!strcmp (vendor_id, "CentaurHauls"))
     {
       /* This is a VIA CPU.  Check what PadLock features we have.  */
-      asm volatile
-        ("pushl %%ebx\n\t"	        /* Save GOT register.  */
-         "movl $0xC0000000, %%eax\n\t"  /* Check for extended centaur  */
-         "cpuid\n\t"                    /* feature flags.              */
-         "popl %%ebx\n\t"	        /* Restore GOT register. */
-         "cmpl $0xC0000001, %%eax\n\t"
-         "jb .Lready%=\n\t"             /* EAX < 0xC0000000 => no padlock.  */
-
-         "pushl %%ebx\n\t"	        /* Save GOT register. */
-         "movl $0xC0000001, %%eax\n\t"  /* Ask for the extended */
-         "cpuid\n\t"                    /* feature flags.       */
-         "popl %%ebx\n\t"	        /* Restore GOT register. */
-
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0x0C, %%eax\n\t"        /* Test bits 2 and 3 to see whether */
-         "cmpl $0x0C, %%eax\n\t"        /* the RNG exists and is enabled.   */
-         "jnz .Lno_rng%=\n\t"
-         "orl $1, %0\n"                 /* Set our HWF_PADLOCK_RNG bit.  */
-
-         ".Lno_rng%=:\n\t"
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0xC0, %%eax\n\t"        /* Test bits 6 and 7 to see whether */
-         "cmpl $0xC0, %%eax\n\t"        /* the ACE exists and is enabled.   */
-         "jnz .Lno_ace%=\n\t"
-         "orl $2, %0\n"                 /* Set our HWF_PADLOCK_AES bit.  */
-
-         ".Lno_ace%=:\n\t"
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0xC00, %%eax\n\t"       /* Test bits 10, 11 to see whether  */
-         "cmpl $0xC00, %%eax\n\t"       /* the PHE exists and is enabled.   */
-         "jnz .Lno_phe%=\n\t"
-         "orl $4, %0\n"                 /* Set our HWF_PADLOCK_SHA bit.  */
-
-         ".Lno_phe%=:\n\t"
-         "movl %%edx, %%eax\n\t"        /* Take copy of feature flags.  */
-         "andl $0x3000, %%eax\n\t"      /* Test bits 12, 13 to see whether  */
-         "cmpl $0x3000, %%eax\n\t"      /* MONTMUL exists and is enabled.   */
-         "jnz .Lready%=\n\t"
-         "orl $8, %0\n"                 /* Set our HWF_PADLOCK_MMUL bit.  */
-
-         ".Lready%=:\n"
-         : "+r" (hw_features)
-         :
-         : "%eax", "%ecx", "%edx", "cc"
-         );
+
+      /* Check for extended centaur (EAX).  */
+      get_cpuid(0xC0000000, &features, NULL, NULL, NULL);
+
+      /* Has extended centaur features? */
+      if (features > 0xC0000000)
+        {
+           /* Ask for the extended feature flags (EDX). */
+           get_cpuid(0xC0000001, NULL, NULL, NULL, &features);
+
+           /* Test bits 2 and 3 to see whether the RNG exists and is enabled. */
+           if ((features & 0x0C) == 0x0C)
+             hw_features |= HWF_PADLOCK_RNG;
+
+           /* Test bits 6 and 7 to see whether the ACE exists and is enabled. */
+           if ((features & 0xC0) == 0xC0)
+             hw_features |= HWF_PADLOCK_AES;
+
+           /* Test bits 10 and 11 to see whether the PHE exists and is
+              enabled.  */
+           if ((features & 0xC00) == 0xC00)
+             hw_features |= HWF_PADLOCK_SHA;
+
+           /* Test bits 12 and 13 to see whether the MONTMUL exists and is
+              enabled.  */
+           if ((features & 0x3000) == 0x3000)
+             hw_features |= HWF_PADLOCK_MMUL;
+        }
     }
 #endif /*ENABLE_PADLOCK_SUPPORT*/
   else if (!strcmp (vendor_id, "GenuineIntel"))
@@ -260,46 +196,27 @@ detect_ia32_gnuc (void)
   else if (!strcmp (vendor_id, "AuthenticAMD"))
     {
       /* This is an AMD CPU.  */
-
     }
 
   /* Detect Intel features, that might also be supported by other
      vendors.  */
+
+  /* Get CPU info and Intel feature flags (ECX).  */
+  get_cpuid(1, NULL, NULL, &features, NULL);
+
 #ifdef ENABLE_AESNI_SUPPORT
-  asm volatile
-    ("pushl %%ebx\n\t"	        /* Save GOT register.  */
-     "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
-     "cpuid\n"
-     "popl %%ebx\n\t"	        /* Restore GOT register. */
-     "testl $0x02000000, %%ecx\n\t" /* Test bit 25.  */
-     "jz .Lno_aes%=\n\t"            /* No AES support.  */
-     "orl $256, %0\n"               /* Set our HWF_INTEL_AES bit.  */
-
-     ".Lno_aes%=:\n"
-     : "+r" (hw_features)
-     :
-     : "%eax", "%ecx", "%edx", "cc"
-     );
+  /* Test bit 25 for AES-NI.  */
+  if (features & 0x02000000)
+     hw_features |= HWF_INTEL_AESNI;
 #endif /*ENABLE_AESNI_SUPPORT*/
 #ifdef ENABLE_DRNG_SUPPORT
-  asm volatile
-    ("pushl %%ebx\n\t"	        /* Save GOT register.  */
-     "movl $1, %%eax\n\t"           /* Get CPU info and feature flags.  */
-     "cpuid\n"
-     "popl %%ebx\n\t"	        /* Restore GOT register. */
-     "testl $0x40000000, %%ecx\n\t" /* Test bit 30.  */
-     "jz .Lno_rdrand%=\n\t"         /* No RDRAND support.  */
-     "orl $512, %0\n"               /* Set our HWF_INTEL_RDRAND bit.  */
-
-     ".Lno_rdrand%=:\n"
-     : "+r" (hw_features)
-     :
-     : "%eax", "%ecx", "%edx", "cc"
-     );
+  /* Test bit 30 for RDRAND.  */
+  if (features & 0x40000000)
+     hw_features |= HWF_INTEL_RDRAND;
 #endif /*ENABLE_DRNG_SUPPORT*/
 
 }
-#endif /* __i386__ && SIZEOF_UNSIGNED_LONG == 4 && __GNUC__ */
+#endif /* HAS_X86_CPUID */
 
 
 /* Detect the available hardware features.  This function is called
@@ -313,24 +230,11 @@ _gcry_detect_hw_features (unsigned int disabled_features)
   if (fips_mode ())
     return; /* Hardware support is not to be evaluated.  */
 
-#if defined (__i386__) && SIZEOF_UNSIGNED_LONG == 4
-# ifdef __GNUC__
-  {
-    detect_ia32_gnuc ();
-  }
-# endif
-#elif defined (__i386__) && SIZEOF_UNSIGNED_LONG == 8
-# ifdef __GNUC__
-  {
-  }
-# endif
-#elif defined (__x86_64__)
-# ifdef __GNUC__
+#if HAS_X86_CPUID
   {
-    detect_x86_64_gnuc ();
+    detect_x86_gnuc ();
   }
-# endif
-#endif
+#endif /* HAS_X86_CPUID */
 
   hw_features &= ~disabled_features;
 }



From wk at gnupg.org  Fri Dec 21 17:28:50 2012
From: wk at gnupg.org (Werner Koch)
Date: Fri, 21 Dec 2012 17:28:50 +0100
Subject: [PATCH] Clean up i386/x86-64 cpuid usage in hwfeatures.c
In-Reply-To: <20121220134657.2475.32324.stgit@localhost6.localdomain6> (Jussi
	Kivilinna's message of "Thu, 20 Dec 2012 15:46:57 +0200")
References: <20121220134657.2475.32324.stgit@localhost6.localdomain6>
Message-ID: <87wqwbqshp.fsf@vigenere.g10code.de>

On Thu, 20 Dec 2012 14:46, jussi.kivilinna at mbnet.fi said:

> For hwfeatures.c clean up, merge i386/x86-64 hardware detection and move
> i386/x86-64 spesific assembler to separate functions, is_cpuid_available() and
> get_cpuid().

Pushed.  I also did some more changes to be prepared for hardware
support on other platforms.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.