> On Wed, Jun 7, 2023 at 5:20 PM Akhil Goyal <gak...@marvell.com> wrote:
> >
> > MACsec SC/SA ids are created based on direction of the flow.
> > Hence, added the missing field for configuration and cleanup
> > of the SCs and SAs.
> >
> > Signed-off-by: Akhil Goyal <gak...@marvell.com>
> > ---
> > devtools/libabigail.abignore | 7 +++++++
> > lib/security/rte_security.c | 16 ++++++++++------
> > lib/security/rte_security.h | 14 ++++++++++----
> > lib/security/rte_security_driver.h | 12 ++++++++++--
> > 4 files changed, 37 insertions(+), 12 deletions(-)
> >
>
> Looking at the report with no supression rule:
> $ abidiff --suppr .../next-cryptodev/devtools/libabigail.abignore
> --no-added-syms --headers-dir1
> .../abi/v23.03/build-gcc-shared/usr/local/include --headers-dir2
> .../next-cryptodev/build-gcc-shared/install/usr/local/include
> .../abi/v23.03/build-gcc-shared/usr/local/lib64/librte_security.so.23.1
> .../next-cryptodev/build-gcc-
> shared/install/usr/local/lib64/librte_security.so.23.2
> Functions changes summary: 0 Removed, 1 Changed (13 filtered out), 0
> Added functions
> Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
>
> 1 function with some indirect sub-type change:
>
> [C] 'function const rte_security_capability*
> rte_security_capabilities_get(rte_security_ctx*)' at
> rte_security.c:241:1 has some indirect sub-type changes:
> parameter 1 of type 'rte_security_ctx*' has sub-type changes:
> in pointed to type 'struct rte_security_ctx' at rte_security.h:69:1:
> type size hasn't changed
> 1 data member change:
> type of 'const rte_security_ops* ops' changed:
> in pointed to type 'const rte_security_ops':
> in unqualified underlying type 'struct rte_security_ops'
> at rte_security_driver.h:230:1:
> type size hasn't changed
> 4 data member changes (4 filtered):
> type of 'security_macsec_sc_create_t
> macsec_sc_create' changed:
> underlying type 'int (void*,
> rte_security_macsec_sc*)*' changed:
> in pointed to type 'function type int (void*,
> rte_security_macsec_sc*)':
> parameter 2 of type 'rte_security_macsec_sc*'
> has sub-type changes:
> in pointed to type 'struct
> rte_security_macsec_sc' at rte_security.h:399:1:
> type size changed from 256 to 320 (in bits)
> 1 data member insertion:
> 'union {struct {uint16_t sa_id[4];
> uint8_t sa_in_use[4]; uint8_t active; uint8_t is_xpn; uint8_t
> reserved;} sc_rx; struct {uint16_t sa_id; uint16_t sa_id_rekey;
> uint64_t sci; uint8_t active; uint8_t re_key_en; uint8_t is_xpn;
> uint8_t reserved;} sc_tx;}', at offset 128 (in bits)
> 1 data member change:
> anonymous data member union {struct
> {uint16_t sa_id[4]; uint8_t sa_in_use[4]; uint8_t active; uint8_t
> reserved;} sc_rx; struct {uint16_t sa_id; uint16_t sa_id_rekey;
> uint64_t sci; uint8_t active; uint8_t re_key_en; uint8_t reserved;}
> sc_tx;} at offset 64 (in bits) became data member 'uint64_t
> pn_threshold'
> and size changed from 192 to 64 (in
> bits) (by -128 bits)
> type of 'security_macsec_sc_destroy_t
> macsec_sc_destroy' changed:
> underlying type 'int (void*, typedef uint16_t)*' changed:
> in pointed to type 'function type int (void*,
> typedef uint16_t)':
> parameter 3 of type 'enum
> rte_security_macsec_direction' was added
> type of 'security_macsec_sc_stats_get_t
> macsec_sc_stats_get' changed:
> underlying type 'int (void*, typedef uint16_t,
> rte_security_macsec_sc_stats*)*' changed:
> in pointed to type 'function type int (void*,
> typedef uint16_t, rte_security_macsec_sc_stats*)':
> parameter 3 of type
> 'rte_security_macsec_sc_stats*' changed:
> entity changed from
> 'rte_security_macsec_sc_stats*' to 'enum
> rte_security_macsec_direction' at rte_security.h:361:1
> type size changed from 64 to 32 (in bits)
> type alignment changed from 0 to 32
> parameter 4 of type
> 'rte_security_macsec_sc_stats*' was added
> type of 'security_macsec_sa_stats_get_t
> macsec_sa_stats_get' changed:
> underlying type 'int (void*, typedef uint16_t,
> rte_security_macsec_sa_stats*)*' changed:
> in pointed to type 'function type int (void*,
> typedef uint16_t, rte_security_macsec_sa_stats*)':
> parameter 3 of type
> 'rte_security_macsec_sa_stats*' changed:
> entity changed from
> 'rte_security_macsec_sa_stats*' to 'enum
> rte_security_macsec_direction' at rte_security.h:361:1
> type size changed from 64 to 32 (in bits)
> type alignment changed from 0 to 32
> parameter 4 of type
> 'rte_security_macsec_sa_stats*' was added
>
> The report complains about the macsec ops type changes.
>
> > diff --git a/devtools/libabigail.abignore b/devtools/libabigail.abignore
> > index c0361bfc7b..14d8fa4293 100644
> > --- a/devtools/libabigail.abignore
> > +++ b/devtools/libabigail.abignore
> > @@ -37,6 +37,13 @@
> > [suppress_type]
> > type_kind = enum
> > changed_enumerators = RTE_CRYPTO_ASYM_XFORM_ECPM,
> RTE_CRYPTO_ASYM_XFORM_TYPE_LIST_END
> > +; Ignore changes to rte_security_ops MACsec APIs which are experimental
> > +[suppress_type]
> > + name = rte_security_ops
> > + has_data_member_inserted_between =
> > + {
> > + offset_of(security_macsec_sc_create_t),
> offset_of(security_macsec_sa_stats_get_t)
> > + }
>
> So I don't get the intent with this rule.
> There is no field named neither security_macsec_sc_create_t nor
> security_macsec_sa_stats_get_t in the rte_security_ops struct.
>
> Now.. why is this rule making the check pass... it is a mystery to me.
> I already hit a case when libabigail ignored statements that are
> invalid or make no sense, so my guess is that this rule is actually
> applied as a simple:
> [suppress_type]
> name = rte_security_ops
>
> And well, this rule is ok from my pov: this rte_security_ops struct
> does not change in size.
> An application is not supposed to know about its content (that is
> defined in a driver header) and all accesses to those ops are supposed
> to be through symbols from the security library.
> So I would go with this "larger" and simpler rule.
The intent was to make it specific to MACsec APIs only.
I am ok with both as these are internal thing and would change it in next
release.
Updated the v3 as per your suggestion.
>
>
> Just a small addition to this, as discussed offlist, this is going to
> be reworked in v23.11 and this rule on rte_security_ops will be
> unneccesary, so please move it in the relevant block (at the end) of
> the libabigail.abignore file.
Ack
