Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp5728448ybf; Thu, 5 Mar 2020 06:03:48 -0800 (PST) X-Google-Smtp-Source: ADFU+vvun6Dn3bjNPj/YvMEtqrP1yoH6wmK/gWLjdgMdy/SaXMcjiJzmdSbENyA2Iywm4I7OWUPg X-Received: by 2002:a9d:4810:: with SMTP id c16mr3169498otf.248.1583417027888; Thu, 05 Mar 2020 06:03:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583417027; cv=none; d=google.com; s=arc-20160816; b=DF12JGAzWETdp/zAsmwMMh+IIwfSo0WTpB1HAQHHpKUQXLZS2DukjJf4Q/gFpNH4wE 6SPNwKR1Ag+x2dOwq3GghIMRsBxvs9KUDU9QVcjo3NHrFrRgc94yNyWQMQIV0jABFVXp wgjt6rjgL5bv9bzw43HyZrlIVRXAScde6Uc4hZPviiDxcXs4bJEEC1bS/Wbn0LlIj2kV jVkwa4ieFUvA2CRX6jqkYFzNzDo4n0kUOBQtuvy4rzcxUpeBTfN18he9RrYsJgX6p8HZ x2hRjsXGDJ/ZyamEHdFKdfpfbQqkvasxoRKg8Q+f0U8bkvKWhQWBey63OrJgzX+K4yGv +Y3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=xdOhYE2PhLeGpIMx1oIEPqye4Ut7jQgvxtzVz26xDX8=; b=w4yED9a2TKcVwxEPuOdaQNK5z30zR4Q4YGXTkbPQ3aj1oSgmn1ULgnm3Tc3YQSGkrL hIJPPXSQ43D9zPOUObOSni5wxuxjaRc/dd6yUVuLFg4dqhXw01OXEaNBJR5fYZYhfVil xMSJcwREQ1TRMDXxO5LnPJLj90M7VPQ1iDgqg162BEaIXk8GuKgAHl0X5HmVghAAkx/f s6pr1wGiAmrh9xT7hQJa1y+r9nAAtwWnbtwBXpYvH6mwqXGZuKcwYGgXp2+kgC/I8drm sjYBKmGoKvcw5uDNv58C1SF+3JDdZkP0qUN5WHHcxJmTkmYjUvuP1AefbET3T+hQjht2 mcqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w20si3694635otj.294.2020.03.05.06.03.26; Thu, 05 Mar 2020 06:03:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726846AbgCEOCp (ORCPT + 99 others); Thu, 5 Mar 2020 09:02:45 -0500 Received: from mx2.suse.de ([195.135.220.15]:40752 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726211AbgCEOCp (ORCPT ); Thu, 5 Mar 2020 09:02:45 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8B58AAB6D; Thu, 5 Mar 2020 14:02:42 +0000 (UTC) Received: by unicorn.suse.cz (Postfix, from userid 1000) id B009BE037F; Thu, 5 Mar 2020 15:02:41 +0100 (CET) Date: Thu, 5 Mar 2020 15:02:41 +0100 From: Michal Kubecek To: netdev@vger.kernel.org Cc: Era Mayflower , davem@davemloft.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] macsec: Netlink support of XPN cipher suites (IEEE 802.1AEbw) Message-ID: <20200305140241.GA28693@unicorn.suse.cz> References: <20200305220108.18780-1-mayflowerera@gmail.com> <20200305220108.18780-2-mayflowerera@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200305220108.18780-2-mayflowerera@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Mar 05, 2020 at 10:01:08PM +0000, Era Mayflower wrote: > Netlink support of extended packet number cipher suites, > allows adding and updating XPN macsec interfaces. > > Added support in: > * Creating interfaces with GCM-AES-XPN-128 and GCM-AES-XPN-256. > * Setting and getting packet numbers with 64bit of SAs. > * Settings and getting ssci of SCs. > * Settings and getting salt of SecYs. > > Depends on: macsec: Support XPN frame handling - IEEE 802.1AEbw. > > Signed-off-by: Era Mayflower > --- [...] > diff --git a/include/net/macsec.h b/include/net/macsec.h > index a0b1d0b5c..3c7914ff1 100644 > --- a/include/net/macsec.h > +++ b/include/net/macsec.h > @@ -11,6 +11,9 @@ > #include > #include > > +#define MACSEC_DEFAULT_PN_LEN 4 > +#define MACSEC_XPN_PN_LEN 8 > + > #define MACSEC_SALT_LEN 12 > > typedef u64 __bitwise sci_t; > diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h > index 024af2d1d..ee424d915 100644 > --- a/include/uapi/linux/if_link.h > +++ b/include/uapi/linux/if_link.h > @@ -462,6 +462,8 @@ enum { > IFLA_MACSEC_SCB, > IFLA_MACSEC_REPLAY_PROTECT, > IFLA_MACSEC_VALIDATION, > + IFLA_MACSEC_SSCI, > + IFLA_MACSEC_SALT, > IFLA_MACSEC_PAD, > __IFLA_MACSEC_MAX, > }; Doesn't this break backword compatibility? You change the value of IFLA_MACSEC_PAD; even if it's only used as padding, if an old client uses it, new kernel will interpret it as IFLA_MACSEC_SSCI (an the same holds for new client with old kernel). > diff --git a/include/uapi/linux/if_macsec.h b/include/uapi/linux/if_macsec.h > index 1d63c43c3..c8fab9673 100644 > --- a/include/uapi/linux/if_macsec.h > +++ b/include/uapi/linux/if_macsec.h > @@ -25,6 +25,8 @@ > /* cipher IDs as per IEEE802.1AEbn-2011 */ > #define MACSEC_CIPHER_ID_GCM_AES_128 0x0080C20001000001ULL > #define MACSEC_CIPHER_ID_GCM_AES_256 0x0080C20001000002ULL > +#define MACSEC_CIPHER_ID_GCM_AES_XPN_128 0x0080C20001000003ULL > +#define MACSEC_CIPHER_ID_GCM_AES_XPN_256 0x0080C20001000004ULL > > /* deprecated cipher ID for GCM-AES-128 */ > #define MACSEC_DEFAULT_CIPHER_ID 0x0080020001000001ULL > @@ -66,6 +68,8 @@ enum macsec_secy_attrs { > MACSEC_SECY_ATTR_INC_SCI, > MACSEC_SECY_ATTR_ES, > MACSEC_SECY_ATTR_SCB, > + MACSEC_SECY_ATTR_SSCI, > + MACSEC_SECY_ATTR_SALT, > MACSEC_SECY_ATTR_PAD, > __MACSEC_SECY_ATTR_END, > NUM_MACSEC_SECY_ATTR = __MACSEC_SECY_ATTR_END, > @@ -78,6 +82,7 @@ enum macsec_rxsc_attrs { > MACSEC_RXSC_ATTR_ACTIVE, /* config/dump, u8 0..1 */ > MACSEC_RXSC_ATTR_SA_LIST, /* dump, nested */ > MACSEC_RXSC_ATTR_STATS, /* dump, nested, macsec_rxsc_stats_attr */ > + MACSEC_RXSC_ATTR_SSCI, /* config/dump, u32 */ > MACSEC_RXSC_ATTR_PAD, > __MACSEC_RXSC_ATTR_END, > NUM_MACSEC_RXSC_ATTR = __MACSEC_RXSC_ATTR_END, The same problem with these two. I'm also a bit unsure about the change of type and length of MACSEC_SA_ATTR_PN but I would have to get more familiar with the code to see if it is really a problem. Michal