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:   Tue, 2 Apr 2019 02:08:09 +0000
From:   Alexei Starovoitov <ast@...com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>
CC:     "jakub.kicinski@...ronome.com" <jakub.kicinski@...ronome.com>,
        "jannh@...gle.com" <jannh@...gle.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH bpf-next 7/7] selftests/bpf: add few verifier scale tests

On 4/1/19 9:35 AM, Daniel Borkmann wrote:
> On 04/01/2019 04:17 PM, Daniel Borkmann wrote:
>> On 03/30/2019 01:16 AM, Alexei Starovoitov wrote:
>>> Add 3 basic tests that stress verifier scalability.
>>>
>>> test_verif_scale1.c calls non-inlined jhash() function 90 times on
>>> different position in the packet.
>>> This test simulates network packet parsing.
>>> jhash function is ~140 instructions and main program is ~1200 insns.
>>>
>>> test_verif_scale2.c force inlines jhash() function 90 times.
>>> This program is ~15k instructions long.
>>>
>>> test_verif_scale3.c calls non-inlined jhash() function 90 times on
>>> But this time jhash has to process 32-bytes from the packet
>>> instead of 14-bytes in tests 1 and 2.
>>> jhash function is ~230 insns and main program is ~1200 insns.
>>>
>>> $ test_progs -s
>>> can be used to see verifier stats.
>>>
>>> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
>>
>> Do you also have some test cases with actual 1M insns resp. such that hit
>> the new complexity limit to check timing / resources it consumes? I think
>> these would be good to have as well as part of selftests.
> 
> (Another thought on why it would be good to have such tests would be to
> see if we would otherwise break long jumps again due to offset truncation
> which we had in the core as well as in JITs in the past.)

llvm truncates jump offsets for large programs.
Unfortunately we need to introduce JA instruction
with 32-bit offset on kernel side before we can fix llvm.
There are plenty of other scalability issues on the kernel side.
This patch set is the first step.
Only non-jumpy program of 1m insn loads and works.
Realistically we're still far away from accepting large programs,
but to get there we need to bump the limit and experience these issues.
I noticed a typo in patch 1, so will respin and will add a test.

Powered by blists - more mailing lists