netdev - Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin

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]

Message-ID: <150dc5d3-21c3-bbb6-6e5b-2ab8ab0e3f38@fb.com>
Date:   Fri, 25 Jan 2019 04:27:02 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jann Horn <jannh@...gle.com>
CC:     "paulmck@...ux.ibm.com" <paulmck@...ux.ibm.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Alexei Starovoitov <ast@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "Network Development" <netdev@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>,
        Ingo Molnar <mingo@...hat.com>,
        Will Deacon <will.deacon@....com>
Subject: Re: [PATCH v4 bpf-next 1/9] bpf: introduce bpf_spin_lock

On 1/24/19 6:38 PM, Alexei Starovoitov wrote:
>> For programs created with CAP_SYS_ADMIN,
>> things get more tricky because you can create your own functions and
>> call them repeatedly; I'm not sure whether the pessimal runtime there
>> becomes exponential, or whether there is some check that catches this.
> I think you're referring to bpf-to-bpf calls.
> The limit it still the same. 4k per program including all calls.
> tail calls are not allowed when bpf-to-bpf is used. So no 32 multiplier.

Jann,

I think you meant
main:
call A
call A
call A
exit
A:
call B
call B
call B
exit
B:
call C
...

scenario when everything fits into 4k?
Would be great if you can construct such test while we're fixing
the rest of the issues brought up in this thread.
It will definitely be no more than BPF_COMPLEXITY_LIMIT_INSNS
which is 128k, but I wonder what will be the actual number of
executed insns.
I think such clever constructed sequence can actually
hit 128k executed too.
It would be awesome test to add to test_verifier.c
We have some of such pushing-the-boundary tests in lib/test_bpf.c
that are generated in assembler.
The longest takes 23853 nanoseconds, but clever bpf2bpf call hack
like above with map_update call in the leaf function should
certainly take much longer.
I accept Paul's challenge to try to get such fancy bpf prog
to take 100 millseconds :)