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  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:21:58 -0700
From:   Luke Nelson <>
To:     Xi Wang <>
Cc:     Ilias Apalodimas <>,
        Jesper Dangaard Brouer <>,
        Will Deacon <>, bpf <>,,,
        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 <>,
        Networking <>,,
        Linux Kernel Mailing List <>,
        Anders Roxell <>,
        Björn Töpel <>
Subject: Re: [PATCH] arm64: bpf: Fix branch offset in JIT

On Mon, Sep 14, 2020 at 11:08 AM Xi Wang <> wrote:
> I don't think there's some consistent semantics of "offsets" across
> the JITs of different architectures (maybe it's good to clean that
> up).  RV64 and RV32 JITs are doing something similar to arm64 with
> respect to offsets.  CCing Björn and Luke.

As I understand it, there are two strategies JITs use to keep track of
the ctx->offset table.

Some JITs (RV32, RV64, arm32, arm64 currently, x86-32) track the end
of each instruction (e.g., ctx->offset[i] marks the beginning of
instruction i + 1).
This requires care to handle jumps to the first instruction to avoid
using ctx->offset[-1]. The RV32 and RV64 JITs have special handling
for this case,
while the arm32, arm64, and x86-32 JITs appear not to. The arm32 and
x32 probably need to be fixed for the same reason arm64 does.

The other strategy is for ctx->offset[i] to track the beginning of
instruction i. The x86-64 JIT currently works this way.
This can be easier to use (no need to special case -1) but looks to be
trickier to construct. This patch changes the arm64 JIT to work this

I don't think either strategy is inherently better, both can be
"correct" as long as the JIT uses ctx->offset in the right way.
This might be a good opportunity to change the JITs to be consistent
about this (especially if the arm32, arm64, and x32 JITs all need to
be fixed anyways).
Having all JITs agree on the meaning of ctx->offset could help future
readers debug / understand the code, and could help to someday verify
ctx->offset construction.

Any thoughts?

- Luke

Powered by blists - more mailing lists