linux.git/include/net/macsec.h, branch v6.6.132

macsec: Enable devices to advertise whether they update sk_buff md_dst during offloads

2024-05-02T14:32:50+00:00

commit 475747a19316b08e856c666a20503e73d7ed67ed upstream.

Omit rx_use_md_dst comment in upstream commit since macsec_ops is not
documented.

Cannot know whether a Rx skb missing md_dst is intended for MACsec or not
without knowing whether the device is able to update this field during an
offload. Assume that an offload to a MACsec device cannot support updating
md_dst by default. Capable devices can advertise that they do indicate that
an skb is related to a MACsec offloaded packet using the md_dst.

Cc: Sabrina Dubroca 
Cc: stable@vger.kernel.org
Fixes: 860ead89b851 ("net/macsec: Add MACsec skb_metadata_dst Rx Data path support")
Signed-off-by: Rahul Rameshbabu 
Reviewed-by: Benjamin Poirier 
Reviewed-by: Cosmin Ratiu 
Reviewed-by: Sabrina Dubroca 
Link: https://lore.kernel.org/r/20240423181319.115860-2-rrameshbabu@nvidia.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman

net: macsec: indicate next pn update when offloading

2023-10-10T08:30:30+00:00

Indicate next PN update using update_pn flag in macsec_context.
Offloaded MACsec implementations does not know whether or not the
MACSEC_SA_ATTR_PN attribute was passed for an SA update and assume
that next PN should always updated, but this is not always true.

The PN can be reset to its initial value using the following command:
$ ip macsec set macsec0 tx sa 0 off #octeontx2-pf case

Or, the update PN command will succeed even if the driver does not support
PN updates.
$ ip macsec set macsec0 tx sa 0 pn 1 on #mscc phy driver case

Comparing the initial PN with the new PN value is not a solution. When
the user updates the PN using its initial value the command will
succeed, even if the driver does not support it. Like this:
$ ip macsec add macsec0 tx sa 0 pn 1 on key 00 \
ead3664f508eb06c40ac7104cdae4ce5
$ ip macsec set macsec0 tx sa 0 pn 1 on #mlx5 case

Signed-off-by: Radu Pirea (NXP OSS) 
Reviewed-by: Sabrina Dubroca 
Signed-off-by: Paolo Abeni

macsec: add functions to get macsec real netdevice and check offload

2023-08-20T09:35:23+00:00

Given a macsec net_device add two functions to return the real net_device
for that device, and check if that macsec device is offloaded or not.

This is needed for auxiliary drivers that implement MACsec offload, but
have flows which are triggered over the macsec net_device, this allows
the drivers in such cases to verify if the device is offloaded or not,
and to access the real device of that macsec device, which would
belong to the driver, and would be needed for the offload procedure.

Signed-off-by: Patrisious Haddad 
Reviewed-by: Raed Salem 
Reviewed-by: Mark Zhang 
Signed-off-by: Leon Romanovsky

macsec: Use helper macsec_netdev_priv for offload drivers

2023-05-10T10:32:09+00:00

Now macsec on top of vlan can be offloaded to macsec offloading
devices so that VLAN tag is sent in clear text on wire i.e,
packet structure is DMAC|SMAC|VLAN|SECTAG. Offloading devices can
simply enable NETIF_F_HW_MACSEC feature in netdev->vlan_features for
this to work. But the logic in offloading drivers to retrieve the
private structure from netdev needs to be changed to check whether
the netdev received is real device or a vlan device and get private
structure accordingly. This patch changes the offloading drivers to
use helper macsec_netdev_priv instead of netdev_priv.

Signed-off-by: Subbaraya Sundeep 
Signed-off-by: David S. Miller

net: macsec: remove the prepare flag from the MACsec offloading context

2022-09-23T13:56:08+00:00

Now that the MACsec offloading preparation phase was removed from the
MACsec core implementation as well as from drivers implementing it, we
can safely remove the flag representing it.

Signed-off-by: Antoine Tenart 
Signed-off-by: Jakub Kicinski

net/macsec: Move some code for sharing with various drivers that implements offload

2022-09-07T13:02:08+00:00

Move some MACsec infrastructure like defines and functions,
in order to avoid code duplication for future drivers which
implements MACsec offload.

Signed-off-by: Lior Nahmanson 
Reviewed-by: Raed Salem 
Reviewed-by: Jiri Pirko 
Reviewed-by: Ben Ben-Ishay 
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller

net/macsec: Add MACsec skb_metadata_dst Tx Data path support

2022-09-07T13:02:08+00:00

In the current MACsec offload implementation, MACsec interfaces shares
the same MAC address by default.
Therefore, HW can't distinguish from which MACsec interface the traffic
originated from.

MACsec stack will use skb_metadata_dst to store the SCI value, which is
unique per Macsec interface, skb_metadat_dst will be used by the
offloading device driver to associate the SKB with the corresponding
offloaded interface (SCI).

Signed-off-by: Lior Nahmanson 
Reviewed-by: Raed Salem 
Signed-off-by: Saeed Mahameed 
Signed-off-by: David S. Miller

net: macsec: Expose MACSEC_SALT_LEN definition to user space

2022-08-19T03:37:35+00:00

Expose MACSEC_SALT_LEN definition to user space to be
used in various user space applications such as iproute.
Iproute will use this as part of adding macsec extended
packet number support.

Reviewed-by: Raed Salem 
Reviewed-by: Sabrina Dubroca 
Signed-off-by: Emeel Hakim 
Link: https://lore.kernel.org/r/20220818153229.4721-1-ehakim@nvidia.com
Signed-off-by: Jakub Kicinski

net: macsec: fix the length used to copy the key for offloading

2021-06-24T19:41:12+00:00

The key length used when offloading macsec to Ethernet or PHY drivers
was set to MACSEC_KEYID_LEN (16), which is an issue as:
- This was never meant to be the key length.
- The key length can be > 16.

Fix this by using MACSEC_MAX_KEY_LEN to store the key (the max length
accepted in uAPI) and secy->key_len to copy it.

Fixes: 3cf3227a21d1 ("net: macsec: hardware offloading infrastructure")
Reported-by: Lior Nahmanson 
Signed-off-by: Antoine Tenart 
Signed-off-by: David S. Miller

net: macsec: add support for getting offloaded stats

2020-03-27T03:17:36+00:00

When HW offloading is enabled, offloaded stats should be used, because
s/w stats are wrong and out of sync with the HW in this case.

Signed-off-by: Dmitry Bogdanov 
Signed-off-by: Mark Starovoytov 
Signed-off-by: Igor Russkikh 
Signed-off-by: David S. Miller