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