netdev - Re: [PATCH xfrm-next v7 6/8] xfrm: speed-up lookup of HW policies

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:   Mon, 21 Nov 2022 10:44:04 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "Jakub Kicinski" <kuba@...nel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH xfrm-next v7 6/8] xfrm: speed-up lookup of HW policies

On Sun, Nov 20, 2022 at 09:17:02PM +0200, Leon Romanovsky wrote:
> On Fri, Nov 18, 2022 at 11:49:07AM +0100, Steffen Klassert wrote:
> > On Thu, Nov 17, 2022 at 02:51:33PM +0200, Leon Romanovsky wrote:
> > > On Thu, Nov 17, 2022 at 01:12:43PM +0100, Steffen Klassert wrote:
> > > > On Wed, Nov 09, 2022 at 02:54:34PM +0200, Leon Romanovsky wrote:
> > > > > From: Leon Romanovsky <leonro@...dia.com>
> > > 
> > > > So this raises the question how to handle acquires with this packet
> > > > offload. 
> > > 
> > > We handle acquires as SW policies and don't offload them.
> > 
> > We trigger acquires with states, not policies. The thing is,
> > we might match a HW policy but create a SW acquire state.
> > This will not match anymore as soon as the lookup is
> > implemented correctly.
> 
> For now, all such packets will be dropped as we have offlaoded
> policy but not SA.

I think you missed my point. If the HW policy does not match
the SW acquire state, then each packet will geneate a new
acquire. So you need to make sure that policy and acquire
state will match to send the acquire just once to userspace.

> > > It is not different from any other kernel code, bugs will be fixed.
> > 
> > The thing that is different here is, that the concept is already
> > broken. We can't split the datapath to be partially handled in
> > SW and HW in any sane way, this becomes clearer and clearer.
> > 
> > The full protocol offload simply does not fit well into HW,
> > but we try to make it fit with a hammer. This is the problem
> > why I do not really like this, and is also the reason why this
> > is still not merged. We might be much better of by doing a
> > HW frindly redesign of the protocol and offload this then.
> > But, yes that takes time and will have issues too.
> 
> When you say "protocol", what do you mean? Many users, who have
> deployed IPsec solutions, just want to have same look and feel
> but much faster.
> 
> I truly believe that this packet offload fits SW model and the
> (small) amount of changes supports it. There are almost no changes
> to the stack to natively support this offload.
> 
> As long as HW involved, you will never have solution without issues,
> and like you said even redesign "will have issues".

Things would be much easier, if we don't need to add HW policies
and states to SW databases. But yes, a redesign might have issues
too. That's why we are still working on the current soluion :)