netdev - Re: 32-bit zext time complexity (Was Re: [PATCH bpf-next] selftests/bpf: two scale tests)

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: <CAMsOgNDumbU7EWmOpwUoXdM5QWZ8h=W5nG3_JTFU5Tju-ofg_A@mail.gmail.com>
Date:   Wed, 1 May 2019 15:59:22 +0100
From:   Jiong Wang <jiong.wang@...ronome.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Networking <netdev@...r.kernel.org>, bpf@...r.kernel.org,
        Jakub Kicinski <jakub.kicinski@...ronome.com>,
        "oss-drivers@...ronome.com" <oss-drivers@...ronome.com>
Subject: Re: 32-bit zext time complexity (Was Re: [PATCH bpf-next]
 selftests/bpf: two scale tests)

> > if you can craft a test that shows patch_insn issue before your set,
> > then it's ok to hack bpf_fill_scale1 to use alu64.
>
> As described above, does the test_verifier 732 + jit blinding looks convincing?
>
> > I would also prefer to go with option 2 (new zext insn) for JITs.
>
> Got it.

I followed option 2 and have sent out v5 with latests changes/fixes:

The major changes are:
  - introduced BPF_ZEXT, even though it doesn't resolve insn patch in-efficient,
    but could let JIT back-ends do optimal code-gen, and the change is small,
    so perhap just better to support it in this set.
  - while look insn patch code, I feel patched-insn need to be conservatiely
    marked if any insn inside patch buffer define sub-register.
  - Also fixed helper function return value handling bug. I am thinking helper
    function should have accurate return value type description, otherwise
    there could be bug. For example arm32 back-end just executes the native
    helper functions and doesn't do anything special on the return value. So
    a function returns u32 would only set native reg r0, not r1 in the pair.
    Then if the outside eBPF insn is casting it into u64, there needs to be
    zext.
  - adjusted test_verifier to make sure it could pass on hosts w and w/o hw
    zext.

For more info, please see the cover letter and patch description at v5.

Thanks.
Regards,
Jiong