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  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:   Mon, 14 Sep 2020 11:52:16 -0700
From:   Xi Wang <>
To:     Ilias Apalodimas <>
Cc:     Jesper Dangaard Brouer <>,
        Will Deacon <>,,,,
        Jean-Philippe Brucker <>,
        Yauheni Kaliuta <>,
        Daniel Borkmann <>,
        Alexei Starovoitov <>,
        Zi Shen Lim <>,
        Catalin Marinas <>,
        Martin KaFai Lau <>,
        Song Liu <>, Yonghong Song <>,
        Andrii Nakryiko <>,
        John Fastabend <>,
        KP Singh <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Jesper Dangaard Brouer <>,,,
        Linux Kernel Mailing List <>,
        Anders Roxell <>,
        Björn Töpel <>,
        Luke Nelson <>
Subject: Re: [PATCH] arm64: bpf: Fix branch offset in JIT

On Mon, Sep 14, 2020 at 11:28 AM Ilias Apalodimas
<> wrote:
> Even if that's true, is any reason at all why we should skip the first element
> of the array, that's now needed since 7c2e988f400 to jump back to the first
> instruction?
> Introducing 2 extra if conditions and hotfix the array on the fly (and for
> every future invocation of that), seems better to you?

My point was that there's no inherently correct/wrong way to construct
offsets.  As Luke explained in his email, 1) there are two different
strategies used by the JITs and 2) there are likely similar bugs
beyond arm64.

Each strategy has pros and cons, and I'm fine with either.  I like the
strategy used in your patch because it's more intuitive (offset[i] is
the start of the emitted instructions for BPF instruction i, rather
than the end), though the changes to the construction process are

If we decide to patch the arm64 JIT the way you proposed, we should
consider whether to change other JITs consistently.

Powered by blists - more mailing lists