netdev - Re: [PATCH net] macsec: Support VLAN-filtering lower devices

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

Message-ID: <5bbb83c9964515526b3d14a43bea492f20f3a0fa.camel@nvidia.com>
Date: Fri, 9 Jan 2026 11:38:59 +0000
From: Cosmin Ratiu <cratiu@...dia.com>
To: "sd@...asysnail.net" <sd@...asysnail.net>
CC: Dragos Tatulea <dtatulea@...dia.com>, "kuba@...nel.org" <kuba@...nel.org>,
	"edumazet@...gle.com" <edumazet@...gle.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "andrew+netdev@...n.ch" <andrew+netdev@...n.ch>,
	"pabeni@...hat.com" <pabeni@...hat.com>, "davem@...emloft.net"
	<davem@...emloft.net>
Subject: Re: [PATCH net] macsec: Support VLAN-filtering lower devices

On Fri, 2026-01-09 at 11:26 +0100, Sabrina Dubroca wrote:
> 2026-01-07, 12:47:23 +0200, Cosmin Ratiu wrote:
> > VLAN-filtering is done through two netdev features
> > (NETIF_F_HW_VLAN_CTAG_FILTER and NETIF_F_HW_VLAN_STAG_FILTER) and
> > two
> > netdev ops (ndo_vlan_rx_add_vid and ndo_vlan_rx_kill_vid).
> > 
> > Implement these and advertise the features if the lower device
> > supports
> > them. This allows proper VLAN filtering to work on top of macsec
> > devices, when the lower device is capable of VLAN filtering.
> > As a concrete example, having this chain of interfaces now works:
> > vlan_filtering_capable_dev(1) -> macsec_dev(2) ->
> > macsec_vlan_dev(3)
> > 
> > Before the "Fixes" commit this used to accidentally work because
> > the
> > macsec device (and thus the lower device) was put in promiscuous
> > mode
> > and the VLAN filter was not used. But after that commit correctly
> > made
> > the macsec driver expose the IFF_UNICAST_FLT flag, promiscuous mode
> > was
> > no longer used and VLAN filters on dev 1 kicked in. Without support
> > in
> > dev 2 for propagating VLAN filters down, the register_vlan_dev ->
> > vlan_vid_add -> __vlan_vid_add -> vlan_add_rx_filter_info call from
> > dev
> > 3 is silently eaten (because vlan_hw_filter_capable returns false
> > and
> > vlan_add_rx_filter_info silently succeeds).
> 
> We only want to propagate VLAN filters when macsec offload is used,
> no? If offload isn't used, the lower device should be unaware of
> whatever is happening on top of macsec, so I don't think non-
> offloaded
> setups are affected by this?

VLAN filters are not related to macsec offload, right? It's about
informing the lower netdevice which VLANs should be allowed. Without
this patch, the VLAN-tagged packets intended for the macsec vlan device
are discarded by the lower device VLAN filter.

> Even when offload is used, the lower device should probably handle
> "ETH + VLAN 5" differently from "ETH + MACSEC + VLAN 5", but that may
> not be possible with just the existing device ops.

I don't see how macsec plays a role into how the lower device handles
VLANs. From the protocol diagrams, I see that it's ETH + VLAN 5 +
MACSEC, the VLAN isn't encrypted if present.

Cosmin.