Bug 1199041

from build.log

...
make  check-TESTS
make[2]: Entering directory '/builddir/build/BUILD/libgcrypt-1.6.2/tests'
version:1.6.2:
ciphers:arcfour:blowfish:cast5:des:aes:twofish:serpent:rfc2268:seed:camellia:idea:salsa20:gost28147:
pubkeys:dsa:elgamal:rsa:ecc:
digests:crc:gostr3411-94:md4:md5:rmd160:sha1:sha256:sha512:tiger:whirlpool:stribog:
rnd-mod:linux:
cpu-arch::
mpi-asm:generic/mpih-add1.c:generic/mpih-sub1.c:generic/mpih-mul1.c:generic/mpih-mul2.c:generic/mpih-mul3.c:generic/mpih-lshift.c:generic/mpih-rshift.c:
threads:none:
hwflist:
fips-mode:n:n:
rng-type:standard:1:
PASS: version
PASS: mpitests
PASS: tsexp
PASS: t-convert
PASS: t-mpi-bit
PASS: t-mpi-point
PASS: curves
PASS: t-lock
PASS: prime
RFC2268 selftest failed (RFC2268 encryption test 1 failed.).
pass 0, algo 307, mode 1, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 2, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 5, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 307, mode 6, gcry_cipher_setkey failed: Selftest failed
FAIL: basic
PASS: keygen
...

when working with upstream (http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=summary)

[sharkcz@tyan-openpower-01 libgcrypt]$ ./tests/basic 
selftest for CFB failed - see syslog for details
pass 0, algo 4, mode 1, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 2, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 5, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 3, gcry_cipher_setkey failed: Selftest failed
pass 0, algo 4, mode 6, gcry_cipher_setkey failed: Selftest failed

syslog/journal contains
Libgcrypt warning: BLOWFISH-CFB-64 test failed (plaintext mismatch)

it seems when functions do_encrypt() and do_encrypt_block() (http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob_plain;f=cipher/blowfish.c;hb=HEAD) both have __attribute__((optimize("O0"))) then the test passes

More info tomorrow.

Created attachment 998718 [details]
preprocessed source

For the ppc64 issue (comment 2) it appears the code is violating C aliasing rules.  With -fno-strict-aliasing the test passes; adding __attribute__ ((optimize("no-strict-aliasing"))) to buf_xor_n_copy helps as well.  I think buf_xor_n_copy_2 accesses "unsigned char *" as a "uintptr_t *".

So, I had a quick look at the s390x tests/basic issue, and bisected that to
http://gcc.gnu.org/r220249 - miscompiled? source is cipher/rfc2268.c in that case.

(In reply to Marek Polacek from comment #4)
> For the ppc64 issue (comment 2) it appears the code is violating C aliasing
> rules.  With -fno-strict-aliasing the test passes; adding __attribute__
> ((optimize("no-strict-aliasing"))) to buf_xor_n_copy helps as well.  I think
> buf_xor_n_copy_2 accesses "unsigned char *" as a "uintptr_t *".

thanks for looking, Marek, I will clone this bug for libgcrypt itself

Self-contained testcase for the s390x rfc2268 issue:

struct S { unsigned short s[64]; };

__attribute__((noinline, noclone)) void
foo (struct S *x)
{
  unsigned int i;
  unsigned char *s;

  s = (unsigned char *) x->s;
  for (i = 0; i < 64; i++)
    x->s[i] = s[i * 2] | (s[i * 2 + 1] << 8);
}  

int
main ()
{
  unsigned int i;
  struct S s;
  for (i = 0; i < 64; i++)
    s.s[i] = i + ((64 - i) << 8);
  foo (&s);
  for (i = 0; i < 64; i++)
    if (s.s[i] != (64 - i) + (i << 8))
      __builtin_abort ();
  return 0;
}

I believe this is ok wrt. strict aliasing, as it is read using a character type.

Forgot -m64 -march=z9-109 -mtune=z10 -O2 -fPIC options.

The problem seems to be that combine_simplify_rtx "simplifies"
(set (mem:HI (plus:DI (reg/v/f:DI 126 [ x ])
            (reg:DI 125 [ ivtmp.11 ])) [2 MEM[base: x_3(D), index: ivtmp.11_41, offset: 0B]+0 S2 A16])
    (ior:HI (subreg:HI (and:SI (subreg:SI (mem:QI (plus:DI (reg/v/f:DI 126 [ x ])
                            (reg:DI 125 [ ivtmp.11 ])) [0 MEM[base: s_4, index: ivtmp.11_41, offset: 0B]+0 S1 A8]) 0)
                (const_int 255 [0xff])) 2)
        (subreg:HI (reg:SI 128 [ D.1536 ]) 2)))
into:
(set (mem:QI (plus:DI (reg/v/f:DI 126 [ x ])
            (reg:DI 125 [ ivtmp.11 ])) [2 MEM[base: x_3(D), index: ivtmp.11_41, offset: 0B]+0 S1 A16])
    (subreg:QI (lshiftrt:SI (reg:SI 128 [ D.1536 ])
            (const_int 8 [0x8])) 3))
Perhaps some hardcoded little endian assumption somewhere?

Sounds like make_extraction or one of its friends.  Given I was just in this code a month or so ago, I'm happy to take it since it's probably my goof.

jeff

Tracking upstream now.
If you want to take it, sure.

when using gcc-5.0.0-0.19.fc22 with http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc5-pr65401.patch applied, the libgcrypt test suite passes on s390x.

Hi,

Sorry to barge in here but I'm running the latest Fedora 21 x86_64 libgcrypt and am getting messages like this:

libgcrypt selftest: pubkey RSA (1): mismatch (encrypt)
libgcrypt selftest: pubkey RSA (1): Selftest failed

Could this be related to what you guys are doing or should I make a new bug report?

Regards,

George...

rpm -q libgcrypt
libgcrypt-1.6.3-1.fc21.x86_64
libgcrypt-1.6.3-1.fc21.i686

> Could this be related to what you guys are doing or should I make a new bug
> report?

Not related, the bug is about Big Endian architectures (ie not x86_64). I suggest you search mailing list archives first, it's been discussed there

gcc-5.0.0-0.21.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/gcc-5.0.0-0.21.fc22

Package gcc-5.0.0-0.21.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gcc-5.0.0-0.21.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4214/gcc-5.0.0-0.21.fc22
then log in and leave karma (feedback).

gcc-5.0.0-0.21.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.