Subject: Re: [pull request][net-next V2 00/15] mlx5 updates 2023-10-19

From: Leon Romanovsky <[email-masked]>
Date: Fri, 27 Oct 2023 13:08:16 +0300

On Thu, Oct 26, 2023 at 05:44:10PM -0700, Saeed Mahameed wrote:
> On 26 Oct 15:46, Jakub Kicinski wrote:
> > On Thu, 26 Oct 2023 15:26:01 -0700 Saeed Mahameed wrote:
> > > When I sent V1 I stripped the fixes tags given that I know this is not an
> > > actual bug fix but rather a missing feature, You asked me to add Fixes
> > > tags when you know this is targeting net-next, and I complied in V2.
> > > 
> > > About Fixes tags strict policy in net-next, it was always a controversy,
> > > I thought you changed your mind, since you explicitly asked me to add the
> > > Fixes tags to a series targeting net-next.
> > 
> > Sorry, I should have been clearer, obviously the policy did not change.
> > I thought you'd know what to do.
> > 
> > > I will submit V3, with Fixes tags removed, Please accept it since Leon
> > > and I agree that this is not a high priority bug fix that needs to be
> > > addressed in -rc7 as Leon already explained.
> > 
> > Patches 3 / 4 are fairly trivial. Patch 7 sounds pretty scary,
> > you're not performing replay validation at all, IIUC.
> > Let me remind you that this is an offload of a security protocol.
> > 
> > BTW I have no idea what "ASO syndrome" is, please put more effort
> > into commit messages.
> 
> ASO stands for (Advanced Steering Operations), it handles the reply
> protection and in case of failure it provides the syndrome, yes I agree the
> commit message needed some work.
> 
> Now given the series is focused on reworking the whole reply protection
> implementation and aligning it with user expectation, and the complexity of
> the patches, I did agree to push it to net-next as the cover letter
> claimed, I am not sure what the severity of this issue in terms of
> security, so I will let Leon decide.

While replay protection attack is real issue, in this specific case, I
didn't see any urgency to push it in -rc7 (most likely, next week will
be merge window [1]). 

IPsec packet offload is supported in crypto flavor ConnectX cards, need
relatively new FW and very new strongswan/libreswan. Also, we (Mellanox)
work very closely with all our partners who needs backports as it is not
trivial.

There are zero or close to zero chances that anyone will run IPsec
offload in production with stable kernel which is not approved by us.

Thanks

[1] https://lwn.net/Articles/948468/