Re: [PATCH 1/3] crypto: mxs-dcp: Add support for hardware provided keys
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date: 2021-07-14 11:01:34
Also in:
keyrings, linux-arm-kernel, linux-doc, linux-integrity, linux-security-module, lkml
Hi, On 14.07.21 12:39, Richard Weinberger wrote:
Ahmad, ----- Ursprüngliche Mail -----quoted
Von: "Ahmad Fatoum" [off-list ref] Let's trade reviews to get the ball rolling?Sounds like a fair deal. :-)
:)
[...]quoted
quoted
--- a/drivers/crypto/mxs-dcp.c +++ b/drivers/crypto/mxs-dcp.c@@ -15,6 +15,7 @@ #include <linux/platform_device.h> #include <linux/stmp_device.h> #include <linux/clk.h> +#include <linux/mxs-dcp.h>The CAAM specific headers are in <soc/fsl/*.h>. Should this be done likewise here as well?I have no preferences. If soc/fsl/ is the way to go, fine by me.
I think it's the more appropriate place, but if the maintainers are fine with <linux/mxs-dcp.h>, I don't mind.
[...]quoted
quoted
@@ -219,15 +224,18 @@ static int mxs_dcp_run_aes(struct dcp_async_ctx *actx, struct dcp *sdcp = global_sdcp; struct dcp_dma_desc *desc = &sdcp->coh->desc[actx->chan]; struct dcp_aes_req_ctx *rctx = skcipher_request_ctx(req); + dma_addr_t src_phys, dst_phys, key_phys = {0};Why = {0}; ? dma_addr_t is a scalar type and the value is always written here before access.Initializing a scalar with {} is allowed in C, the braces are optional. I like the braces because it works even when the underlaying type changes. But that's just a matter of taste. key_phys is initialized because it triggered a false positive gcc warning on one of my targets. Let me re-run again to be sure, the code saw a lot of refactoring since that. [...]quoted
quoted
+static int mxs_dcp_aes_setrefkey(struct crypto_skcipher *tfm, const u8 *key, + unsigned int len) +{ + struct dcp_async_ctx *actx = crypto_skcipher_ctx(tfm); + int ret = -EINVAL; + + if (len != DCP_PAES_KEYSIZE) + goto out;Nitpick: there is no cleanup, so why not return -EINVAL here and unconditionally return 0 below?What is the benefit?
Similar to why you wouldn't write:
if (len == DCP_PAES_KEYSIZE) {
/* longer code block */
}
return ret;
Code is easier to scan through with early-exits.
Usually I try to use goto to have a single exit point of a function but I don't have a strong preference...
It's just a nitpick. I am fine with it either way.
quoted
quoted
+ + actx->key_len = len; + actx->refkey = true; + + switch (key[0]) { + case DCP_PAES_KEY_SLOT0: + case DCP_PAES_KEY_SLOT1: + case DCP_PAES_KEY_SLOT2: + case DCP_PAES_KEY_SLOT3: + case DCP_PAES_KEY_UNIQUE: + case DCP_PAES_KEY_OTP: + memcpy(actx->key, key, len); + ret = 0; + }In the error case you return -EINVAL below, but you still write into actx. Is that intentional?You mean acts->key_len and actk->refkey? Is this a problem?
It's easier to reason about code when it doesn't leave objects it operates on in invalid states on failure. Changing key_len, but leaving actx->key uninitialized is surprising IMO. I can't judge whether this is a problem in practice, but less surprises are a worthwhile goal. Cheers, Ahmad
Thanks, //richard
-- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |