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? Thanks, Horia
