From:   Daniel Axtens <dja@axtens.net>
To:     Ondrej =?utf-8?B?TW9zbsOhxI1law==?= <omosnacek@gmail.com>,
        linux-crypto@vger.kernel.org,
        Herbert Xu <herbert@gondor.apana.org.au>
Cc:     marcelo.cerri@canonical.com, Stephan Mueller <smueller@chronox.de>,
        leo.barbosa@canonical.com, linuxppc-dev@lists.ozlabs.org,
        Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
Subject: Re: BUG: p8_aes_ctr randomly returns wrong results
In-Reply-To: <CAAUqJDtsx6Sdv=6xAb1VWWjDF08y8wh2nsAypR8_x_e99a1Uwg@mail.gmail.com>
References: <CAAUqJDtsx6Sdv=6xAb1VWWjDF08y8wh2nsAypR8_x_e99a1Uwg@mail.gmail.com>
Date:   Fri, 15 Mar 2019 12:26:59 +1100
Message-ID: <878sxhsza4.fsf@dja-thinkpad.axtens.net>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi Ondrej,

> When I run 'rmmod vmx_crypto' before running the reproducer, I get
> only one (correct) checksum, so this is definitely a bug in the
> driver. Other ciphers (cbc(aes), xts(aes)) are not affected, even
> though the glue code is very similar. That leads me to believe the
> problem is somewhere in the assembly code.

It appears that under certain circumstances, aes_p8_ctr32_encrypt_blocks
changes walk.iv. If this is done when
  while ((nbytes = walk.nbytes) >= AES_BLOCK_SIZE) {
is not in its final iteration, it will corrupt the future blocks.

I am not yet sure why this is. Clearly it's pretty late in the assembly
because it doesn't seem to affect the blocks being processed in that
call, only future calls.

Saving and restoring the IV makes the test case pass.

I'll have a look at the asm.

Regards,
Daniel


>
> [1] http://github.com/smuellerDD/libkcapi
>
> Cheers,
> Ondrej