From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-44.mimecast.com (us-smtp-delivery-44.mimecast.com [207.211.30.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FEB37C08E for ; Fri, 19 Apr 2024 15:04:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=207.211.30.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713539063; cv=none; b=XzGpnW8UqPg2+NvMuzOcBRGX4XF0XfLlZEg9VMlBy32LRAvx+KJbc1BhNBX5B4tEXvRJHAaJw4sxExpMh3yTdTqkvtH5pf9S0Bp+jngK5S5xi8vTSbgFr3F8Xd1LLowE40+/NiXG9/wO+tCsWvZ+QJQNUqMKq9QjisyIiOgLWeI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713539063; c=relaxed/simple; bh=BfPC7rSyyC8PwFpTcUkxNnMuZ2RpZN5nSwew3yN8V08=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: In-Reply-To:Content-Type:Content-Disposition; b=BfNsVMjuIZgd/N3pcTAU8PaCZEp9PRbUtXT4nJn0FuZAnC6nmkp76u6JBKgwXBMr9rggYnxlj8cxPboPdE1cx40biYmL6qNak0/yoHieAO4nsCQ6xuUPNGRRiZ8e1waHGwddYpEUkmZ3WoXZmSw/Lha3L+p+o42VOl8nj/LMYFY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net; spf=none smtp.mailfrom=queasysnail.net; arc=none smtp.client-ip=207.211.30.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=queasysnail.net Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=queasysnail.net Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-323-7CD1Fwe2O922ruFHYjUJtg-1; Fri, 19 Apr 2024 11:04:11 -0400 X-MC-Unique: 7CD1Fwe2O922ruFHYjUJtg-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 364278E9E89; Fri, 19 Apr 2024 15:04:10 +0000 (UTC) Received: from hog (unknown [10.39.193.137]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 93AC6581D0; Fri, 19 Apr 2024 15:04:08 +0000 (UTC) Date: Fri, 19 Apr 2024 17:04:07 +0200 From: Sabrina Dubroca To: Rahul Rameshbabu Cc: netdev@vger.kernel.org, stable@vger.kernel.org, Jakub Kicinski , Eric Dumazet , "David S. Miller" , Paolo Abeni , Gal Pressman , Tariq Toukan , Yossi Kuperman , Benjamin Poirier , Cosmin Ratiu Subject: Re: [PATCH net-next 0/3] Resolve security issue in MACsec offload Rx datapath Message-ID: References: <20240419011740.333714-1-rrameshbabu@nvidia.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: <20240419011740.333714-1-rrameshbabu@nvidia.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: queasysnail.net Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable This should go to net, not net-next. It fixes a serious bug. Also please change the title to: fix isolation of broadcast traffic with MACsec offload "resolve security issue" is too vague. 2024-04-18, 18:17:14 -0700, Rahul Rameshbabu wrote: > 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 messa= ge > 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 MACse= c. >=20 > Here is a summary of the issue that occurs with the existing logic today. >=20 > * The current design of the MACsec offload handling path tries to use > "best guess" mechanisms for determining whether a packet associated > with the currently handled skb in the datapath was processed via HW > offload=E2=80=8B nit: there's a strange character after "offload" and at the end of a few other lines in this list > * The best guess mechanism uses the following heuristic logic (in ord= er of > precedence) > - Check if header destination MAC address matches MACsec netdev MAC > address -> forward to MACsec port > - Check if packet is multicast traffic -> forward to MACsec port=E2= =80=8B here ^ > - MACsec security channel was able to be looked up from skb offload > context (mlx5 only) -> forward to MACsec port=E2=80=8B here ^ > * Problem: plaintext traffic can potentially solicit a MACsec encrypt= ed > response from the offload device > - Core aspect of MACsec is that it identifies unauthorized LAN conn= ections > and excludes them from communication > + This behavior can be seen when not enabling offload for MACsec= =E2=80=8B here ^ > - The offload behavior violates this principle in MACsec >=20 >=20 > Link: https://github.com/Binary-Eater/macsec-rx-offload/blob/trunk/MACsec= _violation_in_core_stack_offload_rx_handling.pdf > Link: https://lore.kernel.org/netdev/87r0l25y1c.fsf@nvidia.com/ > Link: https://lore.kernel.org/netdev/20231116182900.46052-1-rrameshbabu@n= vidia.com/ > Cc: Sabrina Dubroca > Cc: stable@vger.kernel.org > Signed-off-by: Rahul Rameshbabu I would put some Fixes tags on this series. Since we can't do anything about non-md_dst devices, I would say that the main patch fixes 860ead89b851 ("net/macsec: Add MACsec skb_metadata_dst Rx Data path support"), and the driver patch fixes b7c9400cbc48 ("net/mlx5e: Implement MACsec Rx data path using MACsec skb_metadata_dst"). Jakub, Rahul, does that sound ok to both of you? --=20 Sabrina