linux-kernel - Re: [RFC bpf-next 1/6] bpf: xfrm: Add bpf_xdp_get_xfrm

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] [day] [month] [year] [list]

Message-ID: <CAADnVQ+anY6G8Xczc1pNmG7Z6k4OEawfGNq0j6guchdRFzLHHg@mail.gmail.com>
Date:   Wed, 1 Nov 2023 11:51:51 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Daniel Xu <dxu@...uu.xyz>
Cc:     Jesper Dangaard Brouer <hawk@...nel.org>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        John Fastabend <john.fastabend@...il.com>,
        Eric Dumazet <edumazet@...gle.com>, antony.antony@...unet.com,
        LKML <linux-kernel@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>, devel@...ux-ipsec.org
Subject: Re: [RFC bpf-next 1/6] bpf: xfrm: Add bpf_xdp_get_xfrm_state() kfunc

On Wed, Nov 1, 2023 at 10:51 AM Daniel Xu <dxu@...uu.xyz> wrote:
>
> Yeah, I agree the code in this patchset is not correct. I have the fix
> (a KF_RELEASE wrapper around xfrm_state_put()) ready to send. I think
> Steffen was gonna chat w/ you about this at IETF next week. But I can
> send it now if you'd like.

I say send a new version with all issues addressed now, since
it might help to frame the discussion at IETF.

>
> To answer your question why it doesn't blow up immediately:
>
> * The test system only has ~33 inbound SAs and the test doesn't try to
>   delete any. So leak is not noticed in the test. Oddly enough I recall
>   `ip x s flush` working correctly... Could be misremembering.
>
> * Refcnt overflow will indeed happen, but some rough math shows it'll
>   take about 12 hrs receiving at 100Gbps for that to happen. 100Gbps =
>   12.5 GB/s. 12.5GB / (32 CPUs) / (9000B) = 43k pps for each pcpu SA.
>   INT_MAX = 2 billion. 2B / 4k = 46k. 46k seconds to hours is ~12 hrs.
>   And I was only running traffic for ~1 hour.
>
> At least I think that math is right.

Makes sense.