From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7FC82C433E2 for ; Tue, 15 Sep 2020 13:55:15 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 11E1E20738 for ; Tue, 15 Sep 2020 13:55:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="TzebHpKl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="pWfAOQep" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11E1E20738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ST7li7fZZyAXE4Mym2Ux0BEspSR1Aibfl5pDrW4i+Pk=; b=TzebHpKlhBU7NtoD/lm83DS8w zOPSSwFnuME5b4OKkrBgMymWIPrSa/8sib77IWszFj1jBCkEgKT+B9ecof4puEsXWkeqWnXVrWY/c fGn26PaDXtJSNu/04CiXaQaNOjVz9JLJV7sz3cZYSzuNuzy0v2XQEtmBaV8L3mR+mF/ikK4/VGmA2 O0yGRSDiMa8Rqdj4BOz/xftst9JjeoPomJl+1c0OPZ78tDs7Gzcw9Kad0VmUAoUPme0FQ+E9Y8v3d L9d4WPRgLKCHxYYyua7pt7/xYSoGPhCU+cK0SeVcTZQFVAGN9u6a4qCGQE3GpqIh6uD7WyvVpREVf qbZWFpQgg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIBP7-0001n2-BI; Tue, 15 Sep 2020 13:53:53 +0000 Received: from mail-wm1-x341.google.com ([2a00:1450:4864:20::341]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIBP4-0001mJ-Qm for linux-arm-kernel@lists.infradead.org; Tue, 15 Sep 2020 13:53:51 +0000 Received: by mail-wm1-x341.google.com with SMTP id w2so3479886wmi.1 for ; Tue, 15 Sep 2020 06:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=mpt5/mY5yPLcWPN5dAxKWZ1iKOvnWN/naNw5pxswiPQ=; b=pWfAOQepoqKVe8FVv3PSRnE2yNbCHL5v9IqR0LbagyAtChnGvMpbyFpYy+ah7a+MDp VHUKM4CuzkFAiSoTN8zgTwkV2aT3nxZP2r7v/FxeCqfIP5gfpAe3HZlsnuuGZ9ccjvYm S1AH7wlrJhWUXEGlA4ipsYAl+ChToZ9akzjOnAQ8MMRU8odgwXVqgE37YELU22uOWKgn 3mAKu2tw8898QfUe05BFKktyMTRrAoo+3ySa3XY0iN33XUiOL7EFVniVk43BB6B7R48Q uVfXKufART+6oiSDUqycqChiI70DAA7zh61WEJ+0JYLEv9ZnvNfbLHoOFVh4eNbifNUu QVow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=mpt5/mY5yPLcWPN5dAxKWZ1iKOvnWN/naNw5pxswiPQ=; b=TcjT3SMKuLUy2W8qa7TTPhYUkvjTTBBYSpBkJfiFxd2ekZ7tPwmNKT0Y1dw4xsGMUb IFazVPskn6wQi54Ob9Rfn6Ejf68yWtsDU6eQuKrrXtpzHm3aXx90C/3OOZ2y/V1UN7/m ryqpT8bToFscr2aD7jNmr3zKtWwQRApwIKcSOrkibLzU97Z4rviWwJSlefuzDnvd+1DN pSD/6LDJzBT6oVS/Nek+5KfvdWHd7dIz1gVkzbMp/r9WPxMK5D7TRLc3pM5MMpIz/Hfs p9MP0oakGJBH+vn7g21okD5LvNFh3zwECid6KbhV0mkNwfozpYRHnoqXzpP8/h4sQBoI Cgjg== X-Gm-Message-State: AOAM531eHFc3ZlO+jyWgr4miiMdOyVqCq7Spa6Bi6C3AOM3mV04WzlKp ERv+f5tUwYoYAAnUlH5ZWTH4rA== X-Google-Smtp-Source: ABdhPJzm5SHWJFNWCUa7kV3RRw1MZ+vh7bUDJxal2VMBlb8NwYHz0xngZah25PvZFFKwKcpd4oT0Kw== X-Received: by 2002:a1c:2bc7:: with SMTP id r190mr4993218wmr.116.1600178027842; Tue, 15 Sep 2020 06:53:47 -0700 (PDT) Received: from apalos.home (athedsl-246545.home.otenet.gr. [85.73.10.175]) by smtp.gmail.com with ESMTPSA id a10sm23545590wmj.38.2020.09.15.06.53.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2020 06:53:47 -0700 (PDT) Date: Tue, 15 Sep 2020 16:53:44 +0300 From: Ilias Apalodimas To: Will Deacon Subject: Re: [PATCH v2] arm64: bpf: Fix branch offset in JIT Message-ID: <20200915135344.GA113966@apalos.home> References: <20200914160355.19179-1-ilias.apalodimas@linaro.org> <20200915131102.GA26439@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200915131102.GA26439@willie-the-truck> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200915_095350_968092_6F7CAEC2 X-CRM114-Status: GOOD ( 34.19 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Song Liu , Zi Shen Lim , Alexei Starovoitov , ardb@kernel.org, Jean-Philippe Brucker , Daniel Borkmann , naresh.kamboju@linaro.org, John Fastabend , Catalin Marinas , Jakub Kicinski , Andrii Nakryiko , Jesper Dangaard Brouer , Yonghong Song , KP Singh , linux-arm-kernel@lists.infradead.org, Yauheni Kaliuta , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "David S. Miller" , Jiri Olsa , bpf@vger.kernel.org, Martin KaFai Lau Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 15, 2020 at 02:11:03PM +0100, Will Deacon wrote: > Hi Ilias, > > On Mon, Sep 14, 2020 at 07:03:55PM +0300, Ilias Apalodimas wrote: > > Running the eBPF test_verifier leads to random errors looking like this: > > > > [ 6525.735488] Unexpected kernel BRK exception at EL1 > > [ 6525.735502] Internal error: ptrace BRK handler: f2000100 [#1] SMP > > Does this happen because we poison the BPF memory with BRK instructions? > Maybe we should look at using a special immediate so we can detect this, > rather than end up in the ptrace handler. As discussed offline this is what aarch64_insn_gen_branch_imm() will return for offsets > 128M and yes replacing the handler with a more suitable message would be good. > > > diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c > > index f8912e45be7a..0974effff58c 100644 > > --- a/arch/arm64/net/bpf_jit_comp.c > > +++ b/arch/arm64/net/bpf_jit_comp.c > > @@ -143,9 +143,13 @@ static inline void emit_addr_mov_i64(const int reg, const u64 val, > > } > > } > > > > -static inline int bpf2a64_offset(int bpf_to, int bpf_from, > > +static inline int bpf2a64_offset(int bpf_insn, int off, > > const struct jit_ctx *ctx) > > { > > + /* arm64 offset is relative to the branch instruction */ > > + int bpf_from = bpf_insn + 1; > > + /* BPF JMP offset is relative to the next instruction */ > > + int bpf_to = bpf_insn + off + 1; > > int to = ctx->offset[bpf_to]; > > /* -1 to account for the Branch instruction */ > > int from = ctx->offset[bpf_from] - 1; > > I think this is a bit confusing with all the variables. How about just > doing: > > /* BPF JMP offset is relative to the next BPF instruction */ > bpf_insn++; > > /* > * Whereas arm64 branch instructions encode the offset from the > * branch itself, so we must subtract 1 from the instruction offset. > */ > return ctx->offset[bpf_insn + off] - ctx->offset[bpf_insn] - 1; > Sure > > @@ -642,7 +646,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, > > > > /* JUMP off */ > > case BPF_JMP | BPF_JA: > > - jmp_offset = bpf2a64_offset(i + off, i, ctx); > > + jmp_offset = bpf2a64_offset(i, off, ctx); > > check_imm26(jmp_offset); > > emit(A64_B(jmp_offset), ctx); > > break; > > @@ -669,7 +673,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx, > > case BPF_JMP32 | BPF_JSLE | BPF_X: > > emit(A64_CMP(is64, dst, src), ctx); > > emit_cond_jmp: > > - jmp_offset = bpf2a64_offset(i + off, i, ctx); > > + jmp_offset = bpf2a64_offset(i, off, ctx); > > check_imm19(jmp_offset); > > switch (BPF_OP(code)) { > > case BPF_JEQ: > > @@ -912,18 +916,26 @@ static int build_body(struct jit_ctx *ctx, bool extra_pass) > > const struct bpf_insn *insn = &prog->insnsi[i]; > > int ret; > > > > + /* > > + * offset[0] offset of the end of prologue, start of the > > + * first insn. > > + * offset[x] - offset of the end of x insn. > > So does offset[1] point at the last arm64 instruction for the first BPF > instruction, or does it point to the first arm64 instruction for the second > BPF instruction? > Right this isn't exactly a good comment. I'll change it to something like: offset[0] - offset of the end of prologue, start of the 1st insn. offset[1] - offset of the end of 1st insn. > > + */ > > + if (ctx->image == NULL) > > + ctx->offset[i] = ctx->idx; > > + > > ret = build_insn(insn, ctx, extra_pass); > > if (ret > 0) { > > i++; > > if (ctx->image == NULL) > > - ctx->offset[i] = ctx->idx; > > + ctx->offset[i] = ctx->offset[i - 1]; > > Does it matter that we set the offset for both halves of a 16-byte BPF > instruction? I think that's a change in behaviour here. Yes it is, but from reading around that's what I understood. for 16-byte eBPF instructions both should point to the start of the corresponding jited arm64 instruction. If I am horribly wrong about this, please shout. > > > continue; > > } > > - if (ctx->image == NULL) > > - ctx->offset[i] = ctx->idx; > > if (ret) > > return ret; > > } > > + if (ctx->image == NULL) > > + ctx->offset[i] = ctx->idx; > > I think it would be cleared to set ctx->offset[0] before the for loop (with > a comment about what it is) and then change the for loop to iterate from 1 > all the way to prog->len. > Sure > Will Thanks /Ilias _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel