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]

Message-ID: <20221121121040.GY704954@gauss3.secunet.de>
Date:   Mon, 21 Nov 2022 13:10:40 +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 Mon, Nov 21, 2022 at 01:34:30PM +0200, Leon Romanovsky wrote:
> 
> Sorry, my bad. But why can't we drop all packets that don't have HW
> state? Why do we need to add larval?

The first packet of a flow tiggers an acquire and inserts a larval
state. On a traffic triggered connection, we need this to get
a state with keys installed.

We need this larval state then, because that tells us we sent already an
acquire to userspace. All subsequent packets of that flow will be
dropped without sending another acquire. Otherwise each subsequent
packet will generate another acquire until the keys are negotiated.
If a flow starts sending on a high rate, this would be not so nice
for userspace :)