Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] crypto: xts - Add support for Cipher Text Stealing
To:     Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>,
        =?UTF-8?B?T25kcmVqIE1vc27DocSNZWs=?= <omosnacek@gmail.com>
Cc:     Pascal van Leeuwen <pascalvanl@gmail.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "rsnel@cube.dyndns.org" <rsnel@cube.dyndns.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
        "davem@davemloft.net" <davem@davemloft.net>
References: <1565074510-8480-1-git-send-email-pvanleeuwen@verimatrix.com>
 <5bf9d0be-3ba4-8903-f1b9-93aa32106274@gmail.com>
 <MN2PR20MB29734CFE2795639436C3CC91CAD50@MN2PR20MB2973.namprd20.prod.outlook.com>
 <MN2PR20MB2973A38A300804281CA6A109CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
 <a0e3ce44-3e47-b8d9-2152-3fd8ba99f09a@gmail.com>
 <MN2PR20MB297333F0024F94C647D71AA2CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
 <52a11506-0047-a7e7-4fa0-ba8d465b843c@gmail.com>
 <MN2PR20MB2973C4EAF89D158B779CDBDACAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
 <46f76b06-004e-c08a-3ef3-4ba9fdc61d91@gmail.com>
 <CAAUqJDuMUHqd4J7TNRbMiEDNeb_GCJPhJUQJoOJo5zXKmL72nQ@mail.gmail.com>
 <MN2PR20MB297367EE650DBA3308ADD134CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
From:   Milan Broz <gmazyland@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <fcf6c4b2-b871-6fdc-7803-f94134148299@gmail.com>
Date:   Thu, 8 Aug 2019 06:35:33 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <MN2PR20MB297367EE650DBA3308ADD134CAD40@MN2PR20MB2973.namprd20.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi,

On 07/08/2019 23:13, Pascal Van Leeuwen wrote:
>> It is a bit confusing, but it is the only reasonable way to support
>> variably sized context and at the same time keep the whole request in
>> a single allocation.

Yes, and the reason here it was detected only for aesni_intel is that
it is submitted though more layers, these depends on variable context length
(at least it run through crypt_simd layer).

I think all other implementations on this 32bit machine were called directly,
so no corruption seen there.

> Ah, ok, I did not know anything about that ... so there's really no way
> I could've done this correctly or to have found the problem myself really.
> Good that it's resolved now, though.
> 
> I fixed a couple of other minor things already, is it OK if I roll this
> into an update to my original patch?

Sure, feel free to fold in my change in v2 patch.
I'll test it and provide Tested-by later.

Maybe it would be good to also include /* must be the last */ comment
to the req in struct, though.

Also, maybe this req should have CRYPTO_MINALIGN_ATTR attribute also?

I expect req can be run through exotic hw accelerators later with some
memory alignment requirements. Ondra will know better here, though ;-)

Thanks!
Milan