netdev - [PATCH RFC net-next v1 0/3] Take advantage of certain device drivers during MACsec offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date: Thu, 16 Nov 2023 10:28:57 -0800
From: Rahul Rameshbabu <rrameshbabu@...dia.com>
To: netdev@...r.kernel.org
Cc: Leon Romanovsky <leon@...nel.org>,
	Saeed Mahameed <saeed@...nel.org>,
	Gal Pressman <gal@...dia.com>,
	Tariq Toukan <tariqt@...dia.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>,
	Rahul Rameshbabu <rrameshbabu@...dia.com>,
	Sabrina Dubroca <sd@...asysnail.net>
Subject: [PATCH RFC net-next v1 0/3] Take advantage of certain device drivers during MACsec offload

Some device drivers support devices that enable them to annotate whether a
Rx skb refers to a packet that was processed by the MACsec offloading
functionality of the device. Logic in the Rx handling for MACsec offload
does not utilize this information to preemptively avoid forwarding to the
macsec netdev currently. Because of this, things like multicast messages
such as ARP requests are forwarded to the macsec netdev whether the message
received was MACsec encrypted or not. The goal of this patch series is to
improve the Rx handling for MACsec offload for devices capable of
annotating skbs received that were decrypted by the NIC offload for MACsec.

Shown below is an example use case where plaintext traffic sent to a
physical port of a NIC configured for MACsec offload is unable to be
handled correctly by the software stack when the NIC provides awareness to
the kernel about whether the received packet is MACsec traffic or not. In
this specific example, plaintext ARP requests are being responded with
MACsec encrypted ARP replies (which leads to routing information being
unable to be built for the requester).

    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

Link: https://lore.kernel.org/netdev/87r0l25y1c.fsf@nvidia.com/
Cc: Sabrina Dubroca <sd@...asysnail.net>
Signed-off-by: Rahul Rameshbabu <rrameshbabu@...dia.com>

Rahul Rameshbabu (3):
  macsec: Enable devices to advertise whether they update sk_buff md_dst
    during offloads
  macsec: Detect if Rx skb is macsec-related for offloading devices that
    update md_dst
  net/mlx5e: Advertise mlx5 ethernet driver updates sk_buff md_dst for
    MACsec

 .../net/ethernet/mellanox/mlx5/core/en_accel/macsec.c |  8 ++++++++
 drivers/net/macsec.c                                  | 11 +++++++++--
 include/net/macsec.h                                  |  1 +
 3 files changed, 18 insertions(+), 2 deletions(-)

-- 
2.40.1