Page MenuHome GnuPG

libgcrypt 1.8.1 fails 2 of 28 testson Red Hat Enterprise Linux 7.4 x86_64
Closed, ResolvedPublic

Description

Ran configure thus : 

$ ./configure --libdir=/usr/local/lib64 --disable-silent-rules \
> --enable-dependency-tracking --enable-static=yes --enable-shared=yes \
> --enable-large-data-tests --enable-hmac-binary-check \
> --disable-O-flag-munging --disable-optimization --with-gnu-ld \
> --with-sysroot=/usr/local --with-libgpg-error-prefix=/usr/local 

That resulted in what seems to be reasonable : 

checking for a BSD-compatible install... /bin/install -c

[... configure output stripped -wk ...]

        Libgcrypt v1.8.1 has been configured as follows:
         
        Platform:                  GNU/Linux (x86_64-pc-linux-gnu)
        Hardware detection module: hwf-x86
        Enabled cipher algorithms: arcfour blowfish cast5 des aes twofish
                                   serpent rfc2268 seed camellia idea salsa20
                                   gost28147 chacha20
        Enabled digest algorithms: crc gostr3411-94 md4 md5 rmd160 sha1
                                   sha256 sha512 sha3 tiger whirlpool stribog
                                   blake2
        Enabled kdf algorithms:    s2k pkdf2 scrypt
        Enabled pubkey algorithms: dsa elgamal rsa ecc
        Random number generator:   default
        Try using jitter entropy:  yes
        Using linux capabilities:  no
        Try using Padlock crypto:  yes
        Try using AES-NI crypto:   yes
        Try using Intel PCLMUL:    yes
        Try using Intel SSE4.1:    yes
        Try using DRNG (RDRAND):   yes
        Try using Intel AVX:       yes
        Try using Intel AVX2:      yes
        Try using ARM NEON:        n/a
        Try using ARMv8 crypto:    n/a
       
The compile ran fine however there were many strange warnings thus : 

libtool: link: warning: library `/usr/local/lib64/libgpg-error.la' was moved.

That makes no sense as libgpg-error.la was not moved and has always been built and installed into /usr/local with the usual libs in /usr/local/lib64 and here is an example : 

gcc -DHAVE_CONFIG_H -I. -I..   -I/usr/local/include -I/usr/local/include -m64 -g -Wl,-rpath=/usr/local/lib64,--enable-new-dtags -malign-double -m128bit-long-double -mpc80 -D_LARGEFILE64_SOURCE -fvisibility=hidden -Wall -MT mpicalc-mpicalc.o -MD -MP -MF .deps/mpicalc-mpicalc.Tpo -c -o mpicalc-mpicalc.o `test -f 'mpicalc.c' || echo './'`mpicalc.c
mv -f .deps/mpicalc-mpicalc.Tpo .deps/mpicalc-mpicalc.Po
/bin/sh ../libtool  --tag=CC   --mode=link gcc -I/usr/local/include -m64 -g -Wl,-rpath=/usr/local/lib64,--enable-new-dtags -malign-double -m128bit-long-double -mpc80 -D_LARGEFILE64_SOURCE -fvisibility=hidden -Wall   -o mpicalc mpicalc-mpicalc.o libgcrypt.la -ldl -L/usr/local/lib64 -lgpg-error 
libtool: link: warning: library `/usr/local/lib64/libgpg-error.la' was moved.
libtool: link: warning: library `/usr/local/lib64/libgpg-error.la' was moved.

Regardless the compile finished with reasonable output thus : 

$ readelf -d ./src/.libs/libgcrypt.so.20.2.1

Dynamic section at offset 0x157dc0 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libgpg-error.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libgcrypt.so.20]
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/local/lib64]
 0x000000000000000c (INIT)               0xb710
 0x000000000000000d (FINI)               0x11c470
 0x0000000000000019 (INIT_ARRAY)         0x3571e0
 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x3571f0
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1f0
 0x0000000000000005 (STRTAB)             0x24c8
 0x0000000000000006 (SYMTAB)             0x950
 0x000000000000000a (STRSZ)              4544 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x358000
 0x0000000000000002 (PLTRELSZ)           1944 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0xaf78
 0x0000000000000007 (RELA)               0x3970
 0x0000000000000008 (RELASZ)             30216 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)             0x38d8
 0x000000006ffffffd (VERDEFNUM)          2
 0x000000006ffffffe (VERNEED)            0x3910
 0x000000006fffffff (VERNEEDNUM)         2
 0x000000006ffffff0 (VERSYM)             0x3688
 0x000000006ffffff9 (RELACOUNT)          1253
 0x0000000000000000 (NULL)               0x0
$ 

A few tests failed where I note the README claims : 

     --enable-hmac-binary-check
                     Include support to check the binary at runtime
                     against a HMAC checksum.  This works only in FIPS
                     mode and on systems providing the dladdr function.

Perhaps that is a problem on Red Hat Enterprise Linux 7.4 but I don't
know. There is no reason that I can see why the non-POSIX Glibc
extension does not exist on this system but perhaps it is an error to
use the extension? I would not know but the test fails:

.
.
.
PASS: prime
libgcrypt selftest: binary  (0): No such file or directory (/usr/local/build/libgcrypt-1.8.1_3.10.0-693.11.1.el7.x86_64.001/src/.libs/.libgcrypt.so.20.hmac)
basic: running self-test failed
FAIL: basic
.
.
.
PASS: t-cv25519
      now running 'basic' test with all hardware features disabled.
libgcrypt selftest: binary  (0): No such file or directory (/usr/local/build/libgcrypt-1.8.1_3.10.0-693.11.1.el7.x86_64.001/src/.libs/.libgcrypt.so.20.hmac)
basic: running self-test failed
FAIL: basic-disable-all-hwf
.
.
.

Perhaps this is related to some "FIPS mode" requirement ? 
I did not see anything in the README nor elsewhere to see what this "FIPS mode" was.

All other tests seems to run fine and this includes the really long tests with 256G of data fed
to the various SHA hash algorithms. However I do note that the "cycles/byte" column is always 
just a blank and someone spelled megabytes as "mebibytes" somewhere.  May want to fix that
in line 581 of tests/bench-slope.c thus :

   567  static void
   568  bench_print_header (int algo_width, const char *algo_name)
   569  {
   570    if (csv_mode)
   571      {
   572        gcry_free (current_algo_name);
   573        current_algo_name = gcry_xstrdup (algo_name);
   574      }
   575    else
   576      {
   577        if (algo_width < 0)
   578          printf (" %-*s | ", -algo_width, algo_name);
   579        else
   580          printf (" %-*s | ", algo_width, algo_name);
   581        printf ("%14s %15s %13s\n", "nanosecs/byte", "mebibytes/sec",
   582                "cycles/byte");
   583      }
   584  }
   585

So that output looks like this : 

PASS: benchmark
Note: bench-slope running in quick regression test mode.
Hash:
                |  nanosecs/byte   mebibytes/sec   cycles/byte
 MD5            |     13.96 ns/B     68.32 MiB/s         - c/B
 SHA1           |     28.70 ns/B     33.23 MiB/s         - c/B
 RIPEMD160      |     41.97 ns/B     22.72 MiB/s         - c/B
 TIGER192       |     14.31 ns/B     66.66 MiB/s         - c/B
 SHA256         |     61.45 ns/B     15.52 MiB/s         - c/B
 SHA384         |     52.70 ns/B     18.10 MiB/s         - c/B
 SHA512         |     49.12 ns/B     19.42 MiB/s         - c/B
 SHA224         |     54.79 ns/B     17.41 MiB/s         - c/B
 MD4            |      7.36 ns/B     129.6 MiB/s         - c/B
 CRC32          |      5.99 ns/B     159.3 MiB/s         - c/B
 CRC32RFC1510   |      5.96 ns/B     160.1 MiB/s         - c/B
 CRC24RFC2440   |      6.04 ns/B     157.8 MiB/s         - c/B
 WHIRLPOOL      |      8.64 ns/B     110.4 MiB/s         - c/B
 TIGER          |     10.36 ns/B     92.03 MiB/s         - c/B
 TIGER2         |     10.36 ns/B     92.04 MiB/s         - c/B
 GOSTR3411_94   |     136.8 ns/B      6.97 MiB/s         - c/B
 STRIBOG256     |     134.8 ns/B      7.07 MiB/s         - c/B
 STRIBOG512     |     147.3 ns/B      6.48 MiB/s         - c/B
 GOSTR3411_CP   |     170.6 ns/B      5.59 MiB/s         - c/B
 SHA3-224       |     15.26 ns/B     62.48 MiB/s         - c/B
 SHA3-256       |     16.17 ns/B     58.99 MiB/s         - c/B
 SHA3-384       |     21.07 ns/B     45.27 MiB/s         - c/B
 SHA3-512       |     30.34 ns/B     31.43 MiB/s         - c/B
 SHAKE128       |     12.71 ns/B     75.05 MiB/s         - c/B
 SHAKE256       |     14.90 ns/B     64.01 MiB/s         - c/B
 BLAKE2B_512    |     24.20 ns/B     39.40 MiB/s         - c/B
 BLAKE2B_384    |     24.66 ns/B     38.67 MiB/s         - c/B
 BLAKE2B_256    |     24.69 ns/B     38.62 MiB/s         - c/B
 BLAKE2B_160    |     22.47 ns/B     42.45 MiB/s         - c/B
 BLAKE2S_256    |     38.31 ns/B     24.89 MiB/s         - c/B
 BLAKE2S_224    |     38.68 ns/B     24.65 MiB/s         - c/B
 BLAKE2S_160    |     38.83 ns/B     24.56 MiB/s         - c/B
 BLAKE2S_128    |     38.85 ns/B     24.55 MiB/s         - c/B
                =

Not sure what cycles per byte should be about.

In any case the testsuite runs for hours and then outputs some spooky results : 

======================================
2 of 28 tests failed
Please report to http://bugs.gnupg.org
======================================
gmake[2]: *** [Makefile:864: check-TESTS] Error 1
gmake[2]: Leaving directory '/usr/local/build/libgcrypt-1.8.1_3.10.0-693.11.1.el7.x86_64.001/tests'
gmake[1]: *** [Makefile:987: check-am] Error 2
gmake[1]: Leaving directory '/usr/local/build/libgcrypt-1.8.1_3.10.0-693.11.1.el7.x86_64.001/tests'
gmake: *** [Makefile:477: check-recursive] Error 1
$ 

Perhaps the "--enable-hmac-binary-check" should be checked in the
configure stage for the required mystery "FIPS mode" as well as
the needed Glibc extension dladdr?

In any case the result can not be installed as is with tests failed. 

Dennis Clarke

Details

Version
libgcrypt 1.8.1

Event Timeline

I see hundreds of lines output but can't easily detect what you question or bug is. Please strip your report down to something we can triage more easy. Also what OS etc. Thanks.

Seems pretty clear. The OS is in the title as Red Hat Enterprise Linux 7.4 on x86_64 and the "bug" is 
simply that the software fails its own testsuite wherein the final output clearly says "Please report to
http://bugs.gnupg.org".

The failed tests are shown clearly and I would think that the software should pass its own tests. It does
do a fantastic job for many hours but fails on two very "basic" tests which would indicate that the result
can not be installed.

Also a minor spelling error which is trivial.

Minor spelling typo :

$ diff -c ./tests/bench-slope.c_backup ./tests/bench-slope.c 
*** ./tests/bench-slope.c_backup        Tue May 23 15:30:34 2017
--- ./tests/bench-slope.c       Mon Dec 11 13:16:35 2017
***************
*** 578,584 ****
          printf (" %-*s | ", -algo_width, algo_name);
        else
          printf (" %-*s | ", algo_width, algo_name);
!       printf ("%14s %15s %13s\n", "nanosecs/byte", "mebibytes/sec",
                "cycles/byte");
      }
  }
--- 578,584 ----
          printf (" %-*s | ", -algo_width, algo_name);
        else
          printf (" %-*s | ", algo_width, algo_name);
!       printf ("%14s %15s %13s\n", "nanosecs/byte", "megabytes/sec",
                "cycles/byte");
      }
  }

Your comments in the output were hard to find. Thus my comment to explain the bug.
You are using non default options and in particular the hmac binary check. The latter was written a couple of years ago for an older Redhat version and it might well be broken in the meantime.

We can't support or test all combinations of options. I would suggest to take this to the mailing list so to get experience from other users.

mebibytes is not a spelling error but the correct unit (abrev is MiB).

Wow. Well thank you Werner becasue I have never seen the term used. It is precisely correct and yet the defacto style of the day seems to be "megabytes" but "mebibytes" is the correct term :

The mebibyte is a multiple of the unit byte for digital information. 
The binary prefix mebi means 2^20, therefore one mebibyte is equal
to 1048576bytes = 1024 kibibytes.

Can't recall ever seeing that ... anywhere. This is interesting over a cup of coffee in the morning.

I just re-compiled libgcrypt-1.8.1 here on RHEL 7.4 again without the "--enable-large-data-tests --enable-hmac-binary-check" options and also removed the "--disable-O-flag-munging --disable-optimization" configure options. I expect to see test results much sooner than before and am still curious about whatever "--enable-hmac-binary-check" is supposed to do.

OKay, mail lists. I didn't see that option but I will subscribe to the gnupg-users list and keep quiet. However in the mean while I can tell you that the removal of the configure options "--enable-large-data-tests --enable-hmac-binary-check --disable-O-flag-munging --disable-optimization " results in perfect test reports. Thank you.

werner claimed this task.

Perhaps as a last word on this it may be reasonable to remove that strange "--enable-hmac-binary-check" as it does cause problems.

It all depends on your system. This is why this is an _option_.