Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <ZEBi8ReG9LKLcmW3@aion.usersys.redhat.com> <ZEuVcizjPtG96/ST@gondor.apana.org.au>
In-Reply-To: <ZEuVcizjPtG96/ST@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 28 Apr 2023 10:57:11 +0100
Message-ID: <CAMj1kXGOxw2mm8dVNHBg3HfJ7==JVV+vdXaW3iGGKamb4ZAg-g@mail.gmail.com>
Subject: Re: RPCSEC GSS krb5 KUnit test fails on arm64 with h/w accelerated
 ciphers enabled
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Scott Mayhew <smayhew@redhat.com>, linux-crypto@vger.kernel.org,
        chuck.lever@oracle.com, linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 28 Apr 2023 at 10:44, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> Scott Mayhew <smayhew@redhat.com> wrote:
> >
> > diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
> > index 0e834a2c062c..477605fad76b 100644
> > --- a/arch/arm64/crypto/aes-modes.S
> > +++ b/arch/arm64/crypto/aes-modes.S
> > @@ -268,6 +268,7 @@ AES_FUNC_START(aes_cbc_cts_encrypt)
> >        add             x4, x0, x4
> >        st1             {v0.16b}, [x4]                  /* overlapping stores */
> >        st1             {v1.16b}, [x0]
> > +       st1             {v1.16b}, [x5]
> >        ret
> > AES_FUNC_END(aes_cbc_cts_encrypt)
> >
> > But I don't know if that change is at all correct! (I've never even
> > looked at arm64 asm before).  If someone who's knowledgeable about this
> > code could chime in, I'd appreciate it.
>
> Ard, could you please take a look at this?
>

The issue seems to be that the caller expects iv_out to have been
populated even when doing ciphertext stealing.

This is meaningless, because the output IV can only be used to chain
additional encrypted data if the split is at a block boundary. The
ciphertext stealing fundamentally terminates the encryption, and
produces a block of ciphertext that is shorter than the block size, so
what the output IV should be is actually unspecified.

IOW, test cases having plain/ciphertext vectors whose size is not a
multiple of the cipher block size should not specify an expected value
for the output IV.