[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r0l25y1c.fsf@nvidia.com>
Date: Mon, 06 Nov 2023 14:15:11 -0800
From: Rahul Rameshbabu <rrameshbabu@...dia.com>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, "David S.
Miller" <davem@...emloft.net>, Saeed Mahameed <saeed@...nel.org>
Subject: Re: [PATCH net] macsec: Abort MACSec Rx offload datapath when skb
is not marked with MACSec metadata
On Wed, 01 Nov, 2023 23:31:33 +0100 Sabrina Dubroca <sd@...asysnail.net> wrote:
> 2023-11-01, 13:02:17 -0700, Rahul Rameshbabu wrote:
>> When MACSec is configured on an outer netdev, traffic received directly
>> through the underlying netdev should not be processed by the MACSec Rx
>> datapath. When using MACSec offload on an outer netdev, traffic with no
>> metadata indicator in the skb is mistakenly considered as MACSec traffic
>> and incorrectly handled in the handle_not_macsec function. Treat skbs with
>> no metadata type as non-MACSec packets rather than assuming they are MACSec
>> packets.
>
> What about the other drivers? mlx5 is the only driver that sets md_dst
> on its macsec skbs, so their offloaded packets just get dropped now?
After taking a deeper look throughout the tree, I realize there are
macsec offloading drivers that do not set md_dst. In this event, we fail
to correctly handle the skb and deliver to the port as you mentioned
previously. Sorry about this miss on my end.
However, I believe that all macsec offload supporting devices run into
the following problem today (including mlx5 devices).
When I configure macsec offload on a device and then vlan on top of the
macsec interface, I become unable to send traffic through the underlying
device.
(can replace mlx5_1 with any ifname of a device that supports macsec offload)
Side 1
ip link del macsec0
ip address flush mlx5_1
ip address add 1.1.1.1/24 dev mlx5_1
ip link set dev mlx5_1 up
ip link add link mlx5_1 macsec0 type macsec sci 1 encrypt on
ip link set dev macsec0 address 00:11:22:33:44:66
ip macsec offload macsec0 mac
ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16
ip macsec add macsec0 rx sci 2 on
ip macsec add macsec0 rx sci 2 sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5
ip address flush macsec0
ip address add 2.2.2.1/24 dev macsec0
ip link set dev macsec0 up
ip link add link macsec0 name macsec_vlan type vlan id 1
ip link set dev macsec_vlan address 00:11:22:33:44:88
ip address flush macsec_vlan
ip address add 3.3.3.1/24 dev macsec_vlan
ip link set dev macsec_vlan up
Side 2
ip link del macsec0
ip address flush mlx5_1
ip address add 1.1.1.2/24 dev mlx5_1
ip link set dev mlx5_1 up
ip link add link mlx5_1 macsec0 type macsec sci 2 encrypt on
ip link set dev macsec0 address 00:11:22:33:44:77
ip macsec offload macsec0 mac
ip macsec add macsec0 tx sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5
ip macsec add macsec0 rx sci 1 on
ip macsec add macsec0 rx sci 1 sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16
ip address flush macsec0
ip address add 2.2.2.2/24 dev macsec0
ip link set dev macsec0 up
ip link add link macsec0 name macsec_vlan type vlan id 1
ip link set dev macsec_vlan address 00:11:22:33:44:99
ip address flush macsec_vlan
ip address add 3.3.3.2/24 dev macsec_vlan
ip link set dev macsec_vlan up
Side 1
ping -I mlx5_1 1.1.1.2
PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 mlx5_1: 56(84) bytes of data.
From 1.1.1.1 icmp_seq=1 Destination Host Unreachable
ping: sendmsg: No route to host
From 1.1.1.1 icmp_seq=2 Destination Host Unreachable
From 1.1.1.1 icmp_seq=3 Destination Host Unreachable
I am thinking the solution is a combination of annotating which macsec
devices support md_dst and this patch. However, I am not sure this fix
would be helpful for devices that support macsec offload without
utilizing md_dst information (would still be problematic).
Would be glad to hear any suggestions you may have before sending out a
v2.
Sorry for the late reply. Was away from a trip and wanted to validate
some things before posting back.
--
Thanks,
Rahul Rameshbabu
Powered by blists - more mailing lists