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

crypto: caam - update IV using HW support

2019-06-20T06:18:33Z

Modify drivers to perform skcipher IV update using the crypto engine, instead of performing the operation in SW. Besides being more efficient, this also fixes IV update for CTR mode. Output HW S/G table is appended with an entry pointing to the same IV buffer used as input (which is now mapped BIDIRECTIONAL). AS (Algorithm State) parameter of the OPERATION command is changed from INIFINAL to INIT in descriptors used by ctr(aes), cbc(aes). This is needed since in case FINAL bit is set, HW skips IV updating in the Context Register for the last data block. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - use len instead of nents for bulding HW S/G table

2019-06-20T06:18:33Z

Currently, conversion of SW S/G table into HW S/G layout relies on nents returned by sg_nents_for_len(sg, len). However this leaves the possibility of HW S/G referencing more data then needed: since buffer length in HW S/G entries is filled using sg_dma_len(sg), the last entry in HW S/G table might have a length that is bigger than needed for the crypto request. This way of S/G table conversion is fine, unless after converting a table more entries have to be appended to the HW S/G table. In this case, crypto engine would access data from the S/G entry having the incorrect length, instead of advancing in the S/G table. This situation doesn't exist, but the upcoming implementation of IV update for skcipher algorithms needs to add a S/G entry after req->dst S/G (corresponding to output IV). Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

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

2019-06-06T06:44:16Z

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

crypto: caam - print messages in caam_dump_sg at debug level

2019-05-30T07:35:45Z

caam_dump_sg() is only compiled in when DEBUG is defined, hence the messages are debug messages. Remove the @level argument from caam_dump_sg() and print all messages at debug level. Signed-off-by: Sascha Hauer Signed-off-by: Herbert Xu

crypto: caam - print debug messages at debug level

2019-05-30T07:35:45Z

The CAAM driver used to put its debug messages inside #ifdef DEBUG and then prints the messages at KERN_ERR level. Replace this with proper functions printing at KERN_DEBUG level. The #ifdef DEBUG gets unnecessary when the right functions are used. This replaces: - print_hex_dump(KERN_ERR ...) inside #ifdef DEBUG with print_hex_dump_debug(...) - dev_err() inside #ifdef DEBUG with dev_dbg() - printk(KERN_ERR ...) inside #ifdef DEBUG with dev_dbg() Some parts of the driver use these functions already, so it is only consequent to use the debug function consistently. Signed-off-by: Sascha Hauer Signed-off-by: Herbert Xu

crypto: caam - remove unused defines

2019-05-30T07:30:30Z

The CAAM driver defines its own debug() macro, but it is unused. Remove it. Signed-off-by: Sascha Hauer Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - print IV only when non NULL

2019-05-30T07:30:30Z

Since eaed71a44ad9 ("crypto: caam - add ecb(*) support") the IV can be NULL, so only dump it when it's non NULL as designated by the ivsize variable. Fixes: eaed71a44ad9 ("crypto: caam - add ecb(*) support") Signed-off-by: Sascha Hauer Signed-off-by: Herbert Xu

crypto: caam - print debugging hex dumps after unmapping

2019-05-23T06:13:09Z

For encryption the destination pointer was still mapped, so the hex dump may be wrong. The IV still contained the input IV while printing instead of the output IV as intended. For decryption the destination pointer was still mapped, so the hex dump may be wrong. The IV dump was correct. Do the hex dumps consistenly after the buffers have been unmapped and in case of IV copied to their final destination. Signed-off-by: Sascha Hauer Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - convert top level drivers to libraries

2019-05-23T06:01:03Z

Currently we allow top level code, i.e. that which sits between the low level (HW-specific) drivers and crypto API, to be built as several drivers: caamalg, caamhash, caam_pkc, caamrng, caamalg_qi. There is no advantage in this, more it interferes with adding support for deferred probing (there are no corresponding devices and thus no bus). Convert these drivers and call init() / exit() manually at the right time. Move algorithms initialization at JR probe / remove time: -the first probed JR registers the crypto algs -the last removed JR unregisters the crypto algs Note: caam_qi_init() is called before JR platform devices creation (of_populate_bus()), such that QI interface is initialized when the caam/qi algorithms are registered in the JR driver (by calling caam_qi_algapi_init(). While here, fix the Kconfig entries under CRYPTO_DEV_FSL_CAAM_JR to be aligned. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu

crypto: caam - fix S/G table passing page boundary

2019-05-23T06:01:03Z

According to CAAM RM: -crypto engine reads 4 S/G entries (64 bytes) at a time, even if the S/G table has fewer entries -it's the responsibility of the user / programmer to make sure this HW behaviour has no side effect The drivers do not take care of this currently, leading to IOMMU faults when the S/G table ends close to a page boundary - since only one page is DMA mapped, while CAAM's DMA engine accesses two pages. Fix this by rounding up the number of allocated S/G table entries to a multiple of 4. Note that in case of two *contiguous* S/G tables, only the last table might needs extra entries. Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu