netdev - Re: [PATCH net 0/5] macsec: offload-related fixes

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]

Date:   Fri, 14 Oct 2022 14:03:57 +0300
From:   Leon Romanovsky <leon@...nel.org>
To:     Sabrina Dubroca <sd@...asysnail.net>
Cc:     netdev@...r.kernel.org, Antoine Tenart <atenart@...nel.org>,
        Mark Starovoytov <mstarovoitov@...vell.com>,
        Igor Russkikh <irusskikh@...vell.com>
Subject: Re: [PATCH net 0/5] macsec: offload-related fixes

On Fri, Oct 14, 2022 at 09:43:45AM +0200, Sabrina Dubroca wrote:
> 2022-10-14, 09:13:39 +0300, Leon Romanovsky wrote:
> > On Thu, Oct 13, 2022 at 04:15:38PM +0200, Sabrina Dubroca wrote:
> > > I'm working on a dummy offload for macsec on netdevsim. It just has a
> > > small SecY and RXSC table so I can trigger failures easily on the
> > > ndo_* side. It has exposed a couple of issues.
> > > 
> > > The first patch will cause some performance degradation, but in the
> > > current state it's not possible to offload macsec to lower devices
> > > that also support ipsec offload. 
> > 
> > Please don't, IPsec offload is available and undergoing review.
> > https://lore.kernel.org/netdev/cover.1662295929.git.leonro@nvidia.com/
> > 
> > This is whole series (XFRM + driver) for IPsec full offload.
> > https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=xfrm-next
> 
> Yes, and that's not upstream yet. 

For this conversation, you can assume what that series is merged.
It is not merged due to request to change how we store XFRM policies
in XFRM core code.

> That patchset is also doing nothing to address the issue I'm refering
> to here, where xfrm_api_check rejects the macsec device because it has
> the NETIF_F_HW_ESP flag (passed from the lower device) and no xfrmdev_ops.

Of course, why do you think that IPsec series should address MACsec bugs?

Thanks