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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Nov 2022 09:23:58 +0100
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     Leon Romanovsky <leon@...nel.org>
CC:     Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        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 Tue, Nov 22, 2022 at 03:54:42PM +0200, Leon Romanovsky wrote:
> On Tue, Nov 22, 2022 at 02:00:02PM +0100, Steffen Klassert wrote:
> > On Tue, Nov 22, 2022 at 08:27:48AM +0200, Leon Romanovsky wrote:
> > > On Tue, Nov 22, 2022 at 12:29:12PM +0800, Herbert Xu wrote:
> > > > On Mon, Nov 21, 2022 at 03:21:45PM +0200, Leon Romanovsky wrote:
> > 
> > Can you please explain why we need host interaction for
> > transport, but not for tunnel mode?
> 
> The main difference is that in transport mode, you must bring packet
> to the kernel in which you configured SA/policy. It means that we must
> ensure that such packets won't be checked again in SW because all packets
> (encrypted and not) pass XFRM logic.
> 
>  - wire -> RX NIC -> kernel -> XFRM stack (we need HW DB here to skip this stage) -> ....
>  ... -> kernel -> XFRM stack (skip for HW SA/policies) -> TX NIC -> wire.
> 
> In tunnel mode, we arrive to XFRM when nothing IPsec related is configured.
> 
>  - wire -> RX PF NIC -> eswitch NIC logic -> TX uplink NIC -> RX
>    representors -> XFRM stack in VM (nothing configured here) -> kernel

Forget about eswitch, VM, etc. for a moment. I'm interested how the
simplest possible tunnel mode cases will work.

Forwarding:

wire -> random NIC RX -> kernel -> IPsec tunnel offload NIC TX -> wire
wire -> IPsec tunnel offload NIC RX -> kernel -> random NIC TX -> wire

Local endpoints:

Application -> kernel -> IPsec tunnel offload NIC TX -> wire
wire -> IPsec tunnel offload NIC RX -> kernel -> Application

These two must work, so how are these cases handled?

If you can do more fancy things with tunnel mode and special NICs
at TX and RX, that's fine but not absolutely required.