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: Fri, 14 Jul 2023 20:30:32 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Leon Romanovsky <leon@...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 Fri, 14 Jul 2023 23:32:58 +0300 Leon Romanovsky wrote:
> On Fri, Jul 14, 2023 at 12:16:33PM -0700, Jakub Kicinski wrote:
> > On Fri, 14 Jul 2023 21:40:13 +0300 Leon Romanovsky wrote:  
> > > It depends on configuration order, if user configures TC first, it will
> > > be a), if he/she configures IPsec first, it will be b).
> > > 
> > > I just think that option b) is really matters.  
> > 
> > And only b) matches what happens in the kernel with policy based IPsec,
> > right?   
> 
> Can you please clarify what do you mean "policy based IPsec"?

I mean without a separate xfrm netdev on which you can install TC
rules of its own.

> > IIUC what you're saying -
> > the result depending on order of configuration may be a major source
> > of surprises / hard to debug problems for the user.  
> 
> When I reviewed patches, I came exactly to an opposite conclusion :)
> 
> My rationale was that users who configure IPsec and TC are advanced
> users who knows their data flow and if they find a) option valuable,
> they can do it.
> 
> For example, a) allows to limit amount of data sent to IPsec engine.
> 
> I believe both a) and b) should be supported.

What does it take to switch between the modes?
Even if we want both modes we should have an explicit switch, I reckon.
Or at least a way to read back what mode we ended up in.