[PATCH] arm64: bpf: Fix branch offset in JIT
will at kernel.org
Mon Sep 14 10:01:15 EDT 2020
On Mon, Sep 14, 2020 at 04:23:50PM +0300, Ilias Apalodimas wrote:
> On Mon, Sep 14, 2020 at 03:35:04PM +0300, Ilias Apalodimas wrote:
> > On Mon, Sep 14, 2020 at 01:20:43PM +0100, Will Deacon wrote:
> > > On Mon, Sep 14, 2020 at 11:36:21AM +0300, Ilias Apalodimas wrote:
> > > > Running the eBPF test_verifier leads to random errors looking like this:
> > > > The reason seems to be the offset creation and usage ctx->offset
> > >
> > > "seems to be"? Are you unsure?
> > Reading the history and other ports of the JIT implementation, I couldn't
> > tell if the decision on skipping the 1st entry was deliberate or not on
> > Aarch64. Reading through the mailist list didn't help either .
> > Skipping the 1st entry seems indeed to cause the problem.
> > I did run the patch though the BPF tests and showed no regressions + fixing
> > the error.
> I'll correct myself here.
> Looking into 7c2e988f400e ("bpf: fix x64 JIT code generation for jmp to 1st insn")
> explains things a bit better.
> Jumping back to the 1st insn wasn't allowed until eBPF bounded loops were
> introduced. That's what the 1st instruction was not saved in the original code.
> > >
> > > No Fixes: tag?
> > I'll re-spin and apply one
> Any suggestion on any Fixes I should apply? The original code was 'correct' and
> broke only when bounded loops and their self-tests were introduced.
Ouch, that's pretty bad as it means nobody is regression testing BPF on
arm64 with mainline. Damn.
The Fixes: tag should identify the commit beyond which we don't need to
backport the fix, so it sounds like introduction of bounded loops, according
to your analysis.
More information about the linux-arm-kernel