On Fri, 9 Aug 2019 at 10:44, Horia Geanta <horia.geanta@xxxxxxx> wrote: > > On 8/9/2019 9:45 AM, Ard Biesheuvel wrote: > > On Fri, 9 Aug 2019 at 05:48, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> On Thu, Aug 08, 2019 at 06:01:49PM +0000, Horia Geanta wrote: > >>> > >>> -- >8 -- > >>> > >>> Subject: [PATCH] crypto: testmgr - Add additional AES-XTS vectors for covering > >>> CTS (part II) > >> > >> Patchwork doesn't like it when you do this and it'll discard > >> your patch. To make it into patchwork you need to put the new > >> Subject in the email headers. > >> > > > > IMO, pretending that your XTS implementation is compliant by only > I've never said that. > Some parts are compliant, some are not. > > > providing test vectors with the last 8 bytes of IV cleared is not the > > right fix for this issue. If you want to be compliant, you will need > It's not a fix. > It's adding test vectors which are not provided in the P1619 standard, > where "data unit sequence number" is at most 5B. > Indeed. But I would prefer not to limit ourselves to 5 bytes of sector numbers in the test vectors. However, we should obviously not add test vectors that are known to cause breakages on hardware that works fine in practice. > > to provide a s/w fallback for these cases. > > > Yes, the plan is to: > > -add 16B IV support for caam versions supporting it - caam Era 9+, > currently deployed in lx2160a and ls108a > > -remove current 8B IV support and add s/w fallback for affected caam versions > I'd assume this could be done dynamically, i.e. depending on IV provided > in the crypto request to use either the caam engine or s/w fallback. > Yes. If the IV received from the caller has bytes 8..15 cleared, you use the limited XTS h/w implementation, otherwise you fall back to xts(ecb-aes-caam..).
