Re: Miscompilation under strict C aliasing rules

[Graham Percival <gperciva@tarsnap.com>]

On Sun, Feb 27, 2022 at 01:00:16PM -0800, Colin Percival wrote:
> On 2/24/22 00:42, Quentin Carbonneaux wrote:
> > Yesterday evening my archival tool started refusing correct
> > passphrases. A bit of debugging revealed a difference of
> > behavior in the blockmix_salsa8() function when compiled
> > with GCC 11.2.0 (straight from the Debian package) with
> > optimization flags -O3.
> 
> Ooh, nasty.  Which version of the scrypt code are you using?  In
> particular, the latest version has a self-test which *should*
> catch issues like this.

FWIW, the "Generic scrypt code is broken - please report bug!" self-test does
catch this.  It was added in
    2015-07-18 Detect and use SSE2 in crypto_scrypt.
    285f41f725eab985d756dc132a36d9b42ab55585

which was part of scrypt 1.2.0, released on 2015-07-30.


I can reproduce this bug on FreeBSD 12.2 on amd64:

    doas /usr/sbin/pkg install gcc11
    cd ~/src/scrypt/build
    make clean
    touch cpusupport-config.h
    make -j3 CC=gcc11 CFLAGS=-O3
    echo "" | ./scrypt enc -P config.h config.h.enc

We need the `touch cpusupport-config.h` to stop scrypt from using the SSE2
code.

gcc12-devel also produces the same "Generic scrypt code is broken"; presumably
due to the same reason, but I haven't tried looking at the dissassembly.
(For the record, I haven't look at the dissassembly from gcc11 either, so
theoretically it might be failing the self-test due to another reason.)

There is no problem with gcc10 or gcc9.

Cheers,
- Graham