netdev - Re: [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support

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-prev] [day] [month] [year] [list]

Message-ID: <ZNQm49Mlo48I63+P@nvidia.com>
Date: Wed, 9 Aug 2023 20:53:07 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Leon Romanovsky <leon@...nel.org>, Leon Romanovsky <leonro@...dia.com>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, linux-rdma@...r.kernel.org,
	Maor Gottlieb <maorg@...dia.com>, Mark Zhang <markzhang@...dia.com>,
	netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
	Patrisious Haddad <phaddad@...dia.com>,
	Raed Salem <raeds@...dia.com>, Saeed Mahameed <saeedm@...dia.com>,
	Simon Horman <horms@...nel.org>
Subject: Re: [PATCH mlx5-next v1 00/14] mlx5 MACsec RoCEv2 support

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