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]

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

Quoting Leon Romanovsky (2022-10-14 13:03:57)
> 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
> 
> > 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?

I was looking at this and the series LGTM. I don't get the above
concern, can you clarify?

If a lower device has both IPsec & MACsec offload capabilities:

- Without the revert: IPsec can be offloaded to the lower dev, MACsec
  can't. That's a bug.

- With the revert: IPsec and MACsec can be offloaded to the lower dev.
  Some features might not propagate to the MACsec dev, which won't allow
  some performance optimizations in the MACsec data path.

Thanks,
Antoine