| Message ID | cover.1691569414.git.leon@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | mlx5 MACsec RoCEv2 support | expand |
On Wed, 9 Aug 2023 11:29:12 +0300 Leon Romanovsky wrote: > This series extends previously added MACsec offload support > to cover RoCE traffic either. > > In order to achieve that, we need configure MACsec with offload between > the two endpoints, like below: > > REMOTE_MAC=10:70:fd:43:71:c0 > > * ip addr add 1.1.1.1/16 dev eth2 > * ip link set dev eth2 up > * ip link add link eth2 macsec0 type macsec encrypt on > * ip macsec offload macsec0 mac > * ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16 > * ip macsec add macsec0 rx port 1 address $REMOTE_MAC > * ip macsec add macsec0 rx port 1 address $REMOTE_MAC sa 0 pn 1 on key 01 ead3664f508eb06c40ac7104cdae4ce5 > * ip addr add 10.1.0.1/16 dev macsec0 > * ip link set dev macsec0 up > > And in a similar manner on the other machine, while noting the keys order > would be reversed and the MAC address of the other machine. > > RDMA traffic is separated through relevant GID entries and in case of IP ambiguity > issue - meaning we have a physical GIDs and a MACsec GIDs with the same IP/GID, we > disable our physical GID in order to force the user to only use the MACsec GID. Can you explain why you need special code to handle this? MACsec is L2, RDMA is L4.
On Wed, 9 Aug 2023 16:09:45 -0700 Jakub Kicinski wrote: > On Wed, 9 Aug 2023 11:29:12 +0300 Leon Romanovsky wrote: > > This series extends previously added MACsec offload support > > to cover RoCE traffic either. > > > > In order to achieve that, we need configure MACsec with offload between > > the two endpoints, like below: > > > > REMOTE_MAC=10:70:fd:43:71:c0 > > > > * ip addr add 1.1.1.1/16 dev eth2 > > * ip link set dev eth2 up > > * ip link add link eth2 macsec0 type macsec encrypt on > > * ip macsec offload macsec0 mac > > * ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16 > > * ip macsec add macsec0 rx port 1 address $REMOTE_MAC > > * ip macsec add macsec0 rx port 1 address $REMOTE_MAC sa 0 pn 1 on key 01 ead3664f508eb06c40ac7104cdae4ce5 > > * ip addr add 10.1.0.1/16 dev macsec0 > > * ip link set dev macsec0 up > > > > And in a similar manner on the other machine, while noting the keys order > > would be reversed and the MAC address of the other machine. > > > > RDMA traffic is separated through relevant GID entries and in case of IP ambiguity > > issue - meaning we have a physical GIDs and a MACsec GIDs with the same IP/GID, we > > disable our physical GID in order to force the user to only use the MACsec GID. > > Can you explain why you need special code to handle this? > MACsec is L2, RDMA is L4. Ah, because you need to support "offload" on device that's not yours.
On Wed, Aug 09, 2023 at 04:09:45PM -0700, Jakub Kicinski wrote: > On Wed, 9 Aug 2023 11:29:12 +0300 Leon Romanovsky wrote: > > This series extends previously added MACsec offload support > > to cover RoCE traffic either. > > > > In order to achieve that, we need configure MACsec with offload between > > the two endpoints, like below: > > > > REMOTE_MAC=10:70:fd:43:71:c0 > > > > * ip addr add 1.1.1.1/16 dev eth2 > > * ip link set dev eth2 up > > * ip link add link eth2 macsec0 type macsec encrypt on > > * ip macsec offload macsec0 mac > > * ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16 > > * ip macsec add macsec0 rx port 1 address $REMOTE_MAC > > * ip macsec add macsec0 rx port 1 address $REMOTE_MAC sa 0 pn 1 on key 01 ead3664f508eb06c40ac7104cdae4ce5 > > * ip addr add 10.1.0.1/16 dev macsec0 > > * ip link set dev macsec0 up > > > > And in a similar manner on the other machine, while noting the keys order > > would be reversed and the MAC address of the other machine. > > > > RDMA traffic is separated through relevant GID entries and in case of IP ambiguity > > issue - meaning we have a physical GIDs and a MACsec GIDs with the same IP/GID, we > > disable our physical GID in order to force the user to only use the MACsec GID. > > Can you explain why you need special code to handle this? > MACsec is L2, RDMA is L4. It is similar in concept to how TCP validates the 5 tuple, and optionally Rx netdev of every packet. The RDMA Rx layer uses a hardware handle for the entire L2/L3 path called the 'GID Index'. It has the interface IP, VLAN information and so on. Logically for MACSEC the 'GID Index' should include the L2 MADSEC association too. For security, at the L4 layer, the RDMA engines enforce that queues can only process packets that are matching the correct 'GID Index'. Ie you cannot Rx a packet on VLAN 10 and have it be delivered to a queue that thinks it is working on VLAN 11. Or Rx on IP A to a queue working on IP B. Same basic principle for MADSEC, rx unencrypted/wrong SA cannot be delivered to a queue that is expecting a certain SA. This HW generation is not able to directly associate the MADSEC L2 information with the GID index. Thus we cannot create distinct GID Indexes for the same IP, same VLAN but differing in MADSEC. Thus if there is an attempt to create two identical GID indexes the driver will prioritize the encrypted one under the idea that is the more secure option in case of misconfiguration. Jason
From: Leon Romanovsky <leonro@nvidia.com> Changelog: v1: * Reordered patches v0: https://lore.kernel.org/all/cover.1691403485.git.leon@kernel.org --------------------------------------------------------------------- From Patrisious: This series extends previously added MACsec offload support to cover RoCE traffic either. In order to achieve that, we need configure MACsec with offload between the two endpoints, like below: REMOTE_MAC=10:70:fd:43:71:c0 * ip addr add 1.1.1.1/16 dev eth2 * ip link set dev eth2 up * ip link add link eth2 macsec0 type macsec encrypt on * ip macsec offload macsec0 mac * ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16 * ip macsec add macsec0 rx port 1 address $REMOTE_MAC * ip macsec add macsec0 rx port 1 address $REMOTE_MAC sa 0 pn 1 on key 01 ead3664f508eb06c40ac7104cdae4ce5 * ip addr add 10.1.0.1/16 dev macsec0 * ip link set dev macsec0 up And in a similar manner on the other machine, while noting the keys order would be reversed and the MAC address of the other machine. RDMA traffic is separated through relevant GID entries and in case of IP ambiguity issue - meaning we have a physical GIDs and a MACsec GIDs with the same IP/GID, we disable our physical GID in order to force the user to only use the MACsec GID. Thanks Patrisious Haddad (14): macsec: add functions to get macsec real netdevice and check offload net/mlx5e: Move MACsec flow steering operations to be used as core library net/mlx5: Remove dependency of macsec flow steering on ethernet net/mlx5e: Rename MACsec flow steering functions/parameters to suit core naming style net/mlx5e: Move MACsec flow steering and statistics database from ethernet to core net/mlx5: Remove netdevice from MACsec steering net/mlx5: Maintain fs_id xarray per MACsec device inside macsec steering RDMA/mlx5: Implement MACsec gid addition and deletion net/mlx5: Add MACsec priorities in RDMA namespaces IB/core: Reorder GID delete code for RoCE net/mlx5: Configure MACsec steering for egress RoCEv2 traffic net/mlx5: Configure MACsec steering for ingress RoCEv2 traffic net/mlx5: Add RoCE MACsec steering infrastructure in core RDMA/mlx5: Handles RoCE MACsec steering rules addition and deletion drivers/infiniband/core/cache.c | 6 +- drivers/infiniband/hw/mlx5/Makefile | 1 + drivers/infiniband/hw/mlx5/macsec.c | 364 +++ drivers/infiniband/hw/mlx5/macsec.h | 29 + drivers/infiniband/hw/mlx5/main.c | 41 +- drivers/infiniband/hw/mlx5/mlx5_ib.h | 17 + .../net/ethernet/mellanox/mlx5/core/Kconfig | 2 +- .../net/ethernet/mellanox/mlx5/core/Makefile | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +- .../mellanox/mlx5/core/en_accel/en_accel.h | 4 +- .../mellanox/mlx5/core/en_accel/macsec.c | 176 +- .../mellanox/mlx5/core/en_accel/macsec.h | 26 +- .../mellanox/mlx5/core/en_accel/macsec_fs.c | 1394 ---------- .../mellanox/mlx5/core/en_accel/macsec_fs.h | 47 - .../mlx5/core/en_accel/macsec_stats.c | 22 +- .../ethernet/mellanox/mlx5/core/en_stats.c | 2 +- .../net/ethernet/mellanox/mlx5/core/fs_cmd.c | 1 + .../net/ethernet/mellanox/mlx5/core/fs_core.c | 37 +- .../mellanox/mlx5/core/lib/macsec_fs.c | 2411 +++++++++++++++++ .../mellanox/mlx5/core/lib/macsec_fs.h | 64 + drivers/net/macsec.c | 15 + include/linux/mlx5/device.h | 2 + include/linux/mlx5/driver.h | 51 + include/linux/mlx5/fs.h | 2 + include/linux/mlx5/macsec.h | 32 + include/net/macsec.h | 2 + 26 files changed, 3122 insertions(+), 1630 deletions(-) create mode 100644 drivers/infiniband/hw/mlx5/macsec.c create mode 100644 drivers/infiniband/hw/mlx5/macsec.h delete mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.c delete mode 100644 drivers/net/ethernet/mellanox/mlx5/core/en_accel/macsec_fs.h create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.c create mode 100644 drivers/net/ethernet/mellanox/mlx5/core/lib/macsec_fs.h create mode 100644 include/linux/mlx5/macsec.h