[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <VI1PR0402MB34850ACE9BD5CC43A150085798CB0@VI1PR0402MB3485.eurprd04.prod.outlook.com>
Date: Fri, 19 Jul 2019 15:06:38 +0000
From: Horia Geanta <horia.geanta@....com>
To: Iuliana Prodan <iuliana.prodan@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Aymen Sghaier <aymen.sghaier@....com>
CC: "David S. Miller" <davem@...emloft.net>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v2 06/14] crypto: caam - check assoclen
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
[...]
> --- a/drivers/crypto/caam/common_if.c
> +++ b/drivers/crypto/caam/common_if.c
> @@ -66,6 +66,23 @@ int check_rfc4106_authsize(unsigned int authsize)
> }
> EXPORT_SYMBOL(check_rfc4106_authsize);
>
> +/*
> + * validate assoclen for RFC4106/RFC4543
> + */
> +int check_ipsec_assoclen(unsigned int assoclen)
> +{
> + switch (assoclen) {
> + case 16:
> + case 20:
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(check_ipsec_assoclen);
> +
It's probably worth making this function (and even the other ones
in common_if) inline.
Herbert, is it worth having these checks moved to crypto API,
so they could be shared b/w all implementations?
This would also provide clear guidance wrt. rules related to
input parameters length.
Thanks,
Horia
Powered by blists - more mailing lists