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. > 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. Horia -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
