kernel/drivers/crypto/caam/caamalg.c, branch linux-5.1.y

crypto: caam - limit output IV to CBC to work around CTR mode DMA issue

2019-07-26T07:12:53Z

commit ed527b13d800dd515a9e6c582f0a73eca65b2e1b upstream. The CAAM driver currently violates an undocumented and slightly controversial requirement imposed by the crypto stack that a buffer referred to by the request structure via its virtual address may not be modified while any scatterlists passed via the same request structure are mapped for inbound DMA. This may result in errors like alg: aead: decryption failed on test 1 for gcm_base(ctr-aes-caam,ghash-generic): ret=74 alg: aead: Failed to load transform for gcm(aes): -2 on non-cache coherent systems, due to the fact that the GCM driver passes an IV buffer by virtual address which shares a cacheline with the auth_tag buffer passed via a scatterlist, resulting in corruption of the auth_tag when the IV is updated while the DMA mapping is live. Since the IV that is returned to the caller is only valid for CBC mode, and given that the in-kernel users of CBC (such as CTS) don't trigger the same issue as the GCM driver, let's just disable the output IV generation for all modes except CBC for the time being. Fixes: 854b06f76879 ("crypto: caam - properly set IV after {en,de}crypt") Cc: Horia Geanta Cc: Iuliana Prodan Reported-by: Sascha Hauer Cc: Signed-off-by: Ard Biesheuvel Reviewed-by: Horia Geanta Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman

crypto: caam - avoid S/G table fetching for AEAD zero-length output

2019-07-26T07:12:25Z

[ Upstream commit dcd9c76e5a183af4f793beb5141efcd260b8d09f ] When enabling IOMMU support, the following issue becomes visible in the AEAD zero-length case. Even though the output sequence length is set to zero, the crypto engine tries to prefetch 4 S/G table entries (since SGF bit is set in SEQ OUT PTR command - which is either generated in SW in case of caam/jr or in HW in case of caam/qi, caam/qi2). The DMA read operation will trigger an IOMMU fault since the address in the SEQ OUT PTR is "dummy" (set to zero / not obtained via DMA API mapping). 1. In case of caam/jr, avoid the IOMMU fault by clearing the SGF bit in SEQ OUT PTR command. 2. In case of caam/qi - setting address, bpid, length to zero for output entry in the compound frame has a special meaning (cf. CAAM RM): "Output frame = Unspecified, Input address = Y. A unspecified frame is indicated by an unused SGT entry (an entry in which the Address, Length, and BPID fields are all zero). SEC obtains output buffers from BMan as prescribed by the preheader." Since no output buffers are needed, modify the preheader by setting (ABS = 1, ADDBUF = 0): -"ABS = 1 means obtain the number of buffers in ADDBUF (0 or 1) from the pool POOL ID" -ADDBUF: "If ABS is set, ADD BUF specifies whether to allocate a buffer or not" 3. In case of caam/qi2, since engine: -does not support FLE[FMT]=2'b11 ("unused" entry) mentioned in DPAA2 RM -requires output entry to be present, even if not used the solution chosen is to leave output frame list entry zeroized. Fixes: 763069ba49d3 ("crypto: caam - handle zero-length AEAD output") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin

crypto: caam - add missing put_device() call

2019-03-07T08:24:52Z

The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Fixes: 35af64038623 ("crypto: caam - Check for CAAM block presence before registering with crypto layer") Fixes: b189817cf789 ("crypto: caam/qi - add ablkcipher and authenc algorithms") Reviewed-by: Horia Geantă Signed-off-by: Wen Yang Signed-off-by: Herbert Xu

crypto: caam - weak key checking for cbc des, 3des

2019-02-15T05:21:55Z

Modify setkey callback for cbc des and 3des to check for weak keys. Signed-off-by: Iuliana Prodan Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - add ecb(*) support

2019-02-15T05:21:55Z

Add ecb mode support for aes, des, 3des and arc4 ciphers. ecb(*) reuses existing skcipher implementation, updating it with support for no IV. Signed-off-by: Iuliana Prodan Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - use mapped_{src,dst}_nents for job descriptor

2019-02-15T05:21:55Z

The mapped_{src,dst}_nents _returned_ from the dma_map_sg call (which could be less than src/dst_nents) have to be used to generate the aead, skcipher job descriptors. Signed-off-by: Iuliana Prodan Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - fixed handling of sg list

2019-02-08T07:30:08Z

when the source sg contains more than 1 fragment and destination sg contains 1 fragment, the caam driver mishandle the buffers to be sent to caam. Fixes: f2147b88b2b1 ("crypto: caam - Convert GCM to new AEAD interface") Cc: # 4.2+ Signed-off-by: Pankaj Gupta Signed-off-by: Arun Pathak Reviewed-by: Horia Geanta Signed-off-by: Herbert Xu

crypto: caam - handle zero-length AEAD output

2019-02-01T06:42:03Z

Recent AEAD changes in testmgr framework introduced by commit a0d608ee5ebf ("crypto: testmgr - unify the AEAD encryption and decryption test vectors") uncovered an error in the CAAM drivers, since they don't correctly handle the case when AEAD output length is zero. Add checks to avoid feeding zero-length req->dst to DMA API. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - fix SHA support detection

2019-01-10T13:37:31Z

The addition of Chacha20 + Poly1305 authenc support inadvertently broke detection of algorithms supported by MDHA (Message Digest Hardware Accelerator), fix it. Fixes: d6bbd4eea243 ("crypto: caam/jr - add support for Chacha20 + Poly1305") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: chacha20-generic - refactor to allow varying number of rounds

2018-11-20T06:26:55Z

In preparation for adding XChaCha12 support, rename/refactor chacha20-generic to support different numbers of rounds. The justification for needing XChaCha12 support is explained in more detail in the patch "crypto: chacha - add XChaCha12 support". The only difference between ChaCha{8,12,20} are the number of rounds itself; all other parts of the algorithm are the same. Therefore, remove the "20" from all definitions, structures, functions, files, etc. that will be shared by all ChaCha versions. Also make ->setkey() store the round count in the chacha_ctx (previously chacha20_ctx). The generic code then passes the round count through to chacha_block(). There will be a ->setkey() function for each explicitly allowed round count; the encrypt/decrypt functions will be the same. I decided not to do it the opposite way (same ->setkey() function for all round counts, with different encrypt/decrypt functions) because that would have required more boilerplate code in architecture-specific implementations of ChaCha and XChaCha. Reviewed-by: Ard Biesheuvel Acked-by: Martin Willi Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu