netdev - Re: [PATCH net-next 09/12] net/mlx5: Compare with old

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: Thu, 13 Jul 2023 21:58:33 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Saeed Mahameed <saeedm@...dia.com>, Jianbo Liu <jianbol@...dia.com>,
	Eric Dumazet <edumazet@...gle.com>, Mark Bloch <mbloch@...dia.com>,
	netdev@...r.kernel.org, Paolo Abeni <pabeni@...hat.com>,
	"David S . Miller" <davem@...emloft.net>,
	Simon Horman <simon.horman@...igine.com>
Subject: Re: [PATCH net-next 09/12] net/mlx5: Compare with old_dest param to
 modify rule destination

On Thu, Jul 13, 2023 at 11:05:56AM -0700, Jakub Kicinski wrote:
> On Thu, 13 Jul 2023 20:43:17 +0300 Leon Romanovsky wrote:
> > > Reads like "can't be triggered with current code", in which case 
> > > the right thing to do is to add "can't be triggered with current
> > > code" to the commit message, rather than the Fixes tag.  
> > 
> > The code is wrong, so comes Fixes line, but I can remove it.
> 
> Yes, perhaps after death we will inhabit a world with clear,
> non-conflicting rules, where law can be followed to the letter
> and "truth" and "good" are clearly and objectively defined.
> 
> Until the sweat release, tho, let's apply common sense, and 
> not add Fixes tags to patches which can't possibly be of interest 
> to backporters.
> 
> Please and thank you...

Sure

> 
> > > I had a look thru the series yesterday, and it looks good to me
> > > (tho I'm no ipsec expert). Thanks for putting in the work!
> > > 
> > > Could you add some info about how the code in the series can be
> > > exercised / example configurations? And please CC Simon, it'd be
> > > great to get him / someone at Corigine to review.
> > > 
> > > And obviously Steffen, why did you not CC Steffen?! :o  
> > 
> > It works exactly like "regular" IPsec, nothing special, except
> > now users can switch to switchdev before adding IPsec rules.
> > 
> >  devlink dev eswitch set pci/0000:06:00.0 mode switchdev
> > 
> > Same configurations as here:
> > https://lore.kernel.org/netdev/cover.1670005543.git.leonro@nvidia.com/
> > Packet offload mode:
> >   ip xfrm state offload packet dev <if-name> dir <in|out>
> >   ip xfrm policy .... offload packet dev <if-name>
> > Crypto offload mode:
> >   ip xfrm state offload crypto dev <if-name> dir <in|out>
> > or (backward compatibility)
> >   ip xfrm state offload dev <if-name> dir <in|out>
> 
> I see, so all policy based IPsec?

Yes, it is.

> Does the order of processing in the device match the kernel?

Yes and this it why this fix was needed to make sure that we update
destinations properly.

> TC packet rewrites or IPsec comes first?

In theory, we support any order, but in real life I don't think that TC
before IPsec is really valuable.

> 
> > I didn't add Steffen as it is more flow steering magic series
> > and not IPsec :).
> > 
> > I'll resubmit on Sunday.
> 
> Thanks!