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;
From:   Horia Geanta <horia.geanta@nxp.com>
To:     Eric Biggers <ebiggers@kernel.org>
CC:     Herbert Xu <herbert@gondor.apana.org.au>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "dm-devel@redhat.com" <dm-devel@redhat.com>
Subject: Re: xts fuzz testing and lack of ciphertext stealing support
Thread-Topic: xts fuzz testing and lack of ciphertext stealing support
Thread-Index: AQHVO/5l0aVU4O6KC0WgPIqEsMQCDg==
Date:   Wed, 17 Jul 2019 17:09:31 +0000
Message-ID: <VI1PR0402MB34857BBB18C2BB8CBA2DEC7198C90@VI1PR0402MB3485.eurprd04.prod.outlook.com>
References: <VI1PR0402MB34858E4EF0ACA7CDB446FF5798CE0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
 <20190716221639.GA44406@gmail.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 279d63aa-25f1-468d-e6d8-08d70ad988d7
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jul 2019 17:09:31.5296
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: horia.geanta@nxp.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0402MB3920
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

On 7/17/2019 1:16 AM, Eric Biggers wrote:=0A=
> Hi Horia,=0A=
> =0A=
> On Tue, Jul 16, 2019 at 05:46:29PM +0000, Horia Geanta wrote:=0A=
>> Hi,=0A=
>>=0A=
>> With fuzz testing enabled, I am seeing xts(aes) failures on caam drivers=
.=0A=
>>=0A=
>> Below are several failures, extracted from different runs:=0A=
>>=0A=
>> [    3.921654] alg: skcipher: xts-aes-caam encryption unexpectedly succe=
eded on test vector "random: len=3D40 klen=3D64"; expected_error=3D-22, cfg=
=3D"random: inplace use_finup nosimd src_divs=3D[57.93%@+11, 37.18%@+164, <=
reimport>0.68%@+4, 0.50%@+305, 3.71%@alignmask+3975]" =0A=
>>=0A=
>> [    3.726698] alg: skcipher: xts-aes-caam encryption unexpectedly succe=
eded on test vector "random: len=3D369 klen=3D64"; expected_error=3D-22, cf=
g=3D"random: inplace may_sleep use_digest src_divs=3D[100.0%@alignmask+584]=
" =0A=
>>=0A=
>> [    3.741082] alg: skcipher: xts-aes-caam encryption unexpectedly succe=
eded on test vector "random: len=3D2801 klen=3D64"; expected_error=3D-22, c=
fg=3D"random: inplace may_sleep use_digest src_divs=3D[100.0%@+6] iv_offset=
=3D18"=0A=
>>=0A=
>> It looks like the problem is not in CAAM driver.=0A=
>> More exactly, fuzz testing is generating random test vectors and running=
=0A=
>> them through both SW generic (crypto/xts.c) and CAAM implementation:=0A=
>> -SW generic implementation of xts(aes) does not support ciphertext steal=
ing=0A=
>> and throws -EINVAL when input is not a multiple of AES block size (16B)=
=0A=
>> -caam has support for ciphertext stealing, and allows for any input size=
=0A=
>> which results in "unexpectedly succeeded" error messages.=0A=
>>=0A=
>> Any suggestion how this should be fixed?=0A=
>>=0A=
>> Thanks,=0A=
>> Horia=0A=
> =0A=
> I don't think drivers should allow inputs the generic implementation does=
n't,=0A=
> since those inputs aren't tested by the crypto self-tests (so how do you =
know=0A=
How about implementation adding static test vectors and using them to valid=
ate=0A=
the standard feature set that's not supported by the generic implementation=
?=0A=
=0A=
> it's even correct?), and people could accidentally rely on the driver-spe=
cific=0A=
> behavior and then be unable to migrate to another platform or implementat=
ion.=0A=
> =0A=
People could also *intentionally* rely on a driver offering an implementati=
on=0A=
that is closer to the spec / standard.=0A=
=0A=
> So for now I recommend just updating the caam driver to return -EINVAL on=
 XTS=0A=
> inputs not evenly divisible by the block size.=0A=
> =0A=
I was hoping for something more constructive...=0A=
=0A=
> Of course, if there are actual use cases for XTS with ciphertext stealing=
 in the=0A=
> kernel, we could add it to all the other implementations too.  But I'm no=
t aware=0A=
> of any currently.  Don't all XTS users in the kernel pass whole blocks?=
=0A=
> =0A=
That's my guess too.=0A=
=0A=
What about user space relying on offloading and xts working=0A=
according to the spec?=0A=
=0A=
Thanks,=0A=
Horia=0A=