| Message ID | 1489064253-3652-2-git-send-email-arend.vanspriel@broadcom.com (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
On Thu, 2017-03-09 at 12:57 +0000, Arend van Spriel wrote: > Since v4.11-rc1 the patch file for crypto/ccm.c, which is > incorporated > in the compat module, no longer applies. Update the patch file to fix > the issue. I think I want to get rid of this ccm thing entirely, any objections? As I remember, it doesn't actually work properly anyway. I suspect that if we really can't do anything else, we'd have to provide a backport for all of crypto/, but I don't want to go there and would rather mandate that all the crypto things are enabled in the base kernel. johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in
On 10-3-2017 7:34, Johannes Berg wrote: > On Thu, 2017-03-09 at 12:57 +0000, Arend van Spriel wrote: >> Since v4.11-rc1 the patch file for crypto/ccm.c, which is >> incorporated >> in the compat module, no longer applies. Update the patch file to fix >> the issue. > > I think I want to get rid of this ccm thing entirely, any objections? > As I remember, it doesn't actually work properly anyway. No objection here. Does the same apply to skcipher stuff? > I suspect that if we really can't do anything else, we'd have to > provide a backport for all of crypto/, but I don't want to go there and > would rather mandate that all the crypto things are enabled in the base > kernel. But that can only work when crypto api in base kernel and backport kernel are the same, right? Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe backports" in
On Fri, 2017-03-10 at 10:49 +0100, Arend Van Spriel wrote: > > On 10-3-2017 7:34, Johannes Berg wrote: > > On Thu, 2017-03-09 at 12:57 +0000, Arend van Spriel wrote: > > > Since v4.11-rc1 the patch file for crypto/ccm.c, which is > > > incorporated > > > in the compat module, no longer applies. Update the patch file to > > > fix > > > the issue. > > > > I think I want to get rid of this ccm thing entirely, any > > objections? > > As I remember, it doesn't actually work properly anyway. > > No objection here. Does the same apply to skcipher stuff? I think so, but not sure. > > I suspect that if we really can't do anything else, we'd have to > > provide a backport for all of crypto/, but I don't want to go there > > and > > would rather mandate that all the crypto things are enabled in the > > base > > kernel. > > But that can only work when crypto api in base kernel and backport > kernel are the same, right? No, I meant adding all of crypto/ to copy-list and making sure *that* works across kernels ... johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in
On 10-3-2017 10:52, Johannes Berg wrote: > On Fri, 2017-03-10 at 10:49 +0100, Arend Van Spriel wrote: >> >> On 10-3-2017 7:34, Johannes Berg wrote: >>> On Thu, 2017-03-09 at 12:57 +0000, Arend van Spriel wrote: >>>> Since v4.11-rc1 the patch file for crypto/ccm.c, which is >>>> incorporated >>>> in the compat module, no longer applies. Update the patch file to >>>> fix >>>> the issue. >>> >>> I think I want to get rid of this ccm thing entirely, any >>> objections? >>> As I remember, it doesn't actually work properly anyway. >> >> No objection here. Does the same apply to skcipher stuff? > > I think so, but not sure. > >>> I suspect that if we really can't do anything else, we'd have to >>> provide a backport for all of crypto/, but I don't want to go there >>> and >>> would rather mandate that all the crypto things are enabled in the >>> base >>> kernel. >> >> But that can only work when crypto api in base kernel and backport >> kernel are the same, right? > > No, I meant adding all of crypto/ to copy-list and making sure *that* > works across kernels ... Understand. There seem to have been significant changes in crypto land making this a challenge. Still seems like right idea. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe backports" in
> > No, I meant adding all of crypto/ to copy-list and making sure > > *that* > > works across kernels ... > > Understand. There seem to have been significant changes in crypto > land making this a challenge. Still seems like right idea. I'm not really sure it's the right idea, it seems like it'll be quite complicated ... :) johannes -- To unsubscribe from this list: send the line "unsubscribe backports" in
diff --git a/patches/crypto-ccm.patch b/patches/crypto-ccm.patch index 8bdea3d..7a44d37 100644 --- a/patches/crypto-ccm.patch +++ b/patches/crypto-ccm.patch @@ -1,7 +1,7 @@ --- a/compat/crypto-ccm.c +++ b/compat/crypto-ccm.c -@@ -13,13 +13,44 @@ - #include <crypto/internal/aead.h> +@@ -14,13 +14,44 @@ + #include <crypto/internal/hash.h> #include <crypto/internal/skcipher.h> #include <crypto/scatterwalk.h> +#include <crypto/algapi.h> @@ -46,7 +46,7 @@ struct ccm_instance_ctx { struct crypto_skcipher_spawn ctr; -@@ -897,7 +928,7 @@ static struct crypto_template crypto_rfc +@@ -1001,7 +1032,7 @@ static int cbcmac_create(struct crypto_template *tmpl, struct rtattr **tb) .module = THIS_MODULE, }; @@ -55,7 +55,7 @@ { int err; -@@ -923,18 +954,9 @@ out_undo_base: +@@ -1033,19 +1064,10 @@ static int __init crypto_ccm_module_init(void) goto out; } @@ -65,6 +65,7 @@ crypto_unregister_template(&crypto_rfc4309_tmpl); crypto_unregister_template(&crypto_ccm_tmpl); crypto_unregister_template(&crypto_ccm_base_tmpl); + crypto_unregister_template(&crypto_cbcmac_tmpl); } - -module_init(crypto_ccm_module_init);
Since v4.11-rc1 the patch file for crypto/ccm.c, which is incorporated in the compat module, no longer applies. Update the patch file to fix the issue. Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com> --- patches/crypto-ccm.patch | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)