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
| ||
|
Message-ID: <DM4PR12MB535741462D5FC1D5F4014896C9349@DM4PR12MB5357.namprd12.prod.outlook.com> Date: Sun, 30 Oct 2022 15:02:20 +0000 From: Raed Salem <raeds@...dia.com> To: Raed Salem <raeds@...dia.com>, Leon Romanovsky <leon@...nel.org>, Sabrina Dubroca <sd@...asysnail.net> CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>, Antoine Tenart <atenart@...nel.org>, Mark Starovoytov <mstarovoitov@...vell.com>, Igor Russkikh <irusskikh@...vell.com> Subject: RE: [PATCH net v2 1/5] Revert "net: macsec: report real_dev features when HW offloading is enabled" >>On Wed, Oct 26, 2022 at 11:56:23PM +0200, Sabrina Dubroca wrote: >>> This reverts commit c850240b6c4132574a00f2da439277ab94265b66. >>> >>> That commit tried to improve the performance of macsec offload by >>> taking advantage of some of the NIC's features, but in doing so, >>> broke macsec offload when the lower device supports both macsec and >>> ipsec offload, as the ipsec offload feature flags (mainly >>> NETIF_F_HW_ESP) were copied from the real device. Since the macsec >>> device doesn't provide xdo_* ops, the XFRM core rejects the >>> registration of the new macsec device in xfrm_api_check. >>> >>> Example perf trace when running >>> ip link add link eni1np1 type macsec port 4 offload mac >>> >>> ip 737 [003] 795.477676: probe:xfrm_dev_event__REGISTER >>name="macsec0" features=0x1c000080014869 >>> xfrm_dev_event+0x3a >>> notifier_call_chain+0x47 >>> register_netdevice+0x846 >>> macsec_newlink+0x25a >>> >>> ip 737 [003] 795.477687: probe:xfrm_dev_event__return >ret=0x8002 >>(NOTIFY_BAD) >>> notifier_call_chain+0x47 >>> register_netdevice+0x846 >>> macsec_newlink+0x25a >>> >>> dev->features includes NETIF_F_HW_ESP (0x04000000000000), so >>> xfrm_api_check returns NOTIFY_BAD because we don't have >>> dev->xfrmdev_ops on the macsec device. >>> >>> We could probably propagate GSO and a few other features from the >>> lower device, similar to macvlan. This will be done in a future patch. >>> >>> Signed-off-by: Sabrina Dubroca <sd@...asysnail.net> >>> --- >>> drivers/net/macsec.c | 27 ++++----------------------- >>> 1 file changed, 4 insertions(+), 23 deletions(-) >>> >> >>It is still mystery for me why mlx5 works. >I think it works when the offload enablement on the macsec device is done >after the macsec netdev creation stage i.e.: >Ip link add link eni1np1 type macsec port 4 Then ip macsec offload >$MACSEC_IF mac I think this path skips xfrm core rejection Further check it shows that xfrm_api_check fails in both configuration flavors, in first method because of register_netdevice call the second method because of netdev_update_features call, however, using the second method (that "works") masks this error so user space is not aware of it, hence why the second method works. >> >>Thanks, >>Reviewed-by: Leon Romanovsky <leonro@...dia.com>
Powered by blists - more mailing lists