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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 849BFC433F5 for ; Tue, 10 May 2022 11:45:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241205AbiEJLte (ORCPT ); Tue, 10 May 2022 07:49:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241196AbiEJLta (ORCPT ); Tue, 10 May 2022 07:49:30 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4AEC25470E for ; Tue, 10 May 2022 04:45:32 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id dk23so32383082ejb.8 for ; Tue, 10 May 2022 04:45:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version; bh=7CJgZK/Q3TXpdrc82+EsjW+w5ztoxNGdpsgGltu/dv8=; b=M6Kk70C20E34EyBk6iNsYOcQRG7DQcgLbFdyEulG2ocYzl7J0XnWxHqsZIlR6UUzud OggPoFqx5m1Honn9I0w1BZnKD7rmMc3Tfmd+LacWlFoMg4qkRs2ztQlOjdaifDQKDUFL PLpQc2nzaqrCYxqW7NDsqgcBWA3RhV/Oy2qFI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version; bh=7CJgZK/Q3TXpdrc82+EsjW+w5ztoxNGdpsgGltu/dv8=; b=KiVpL0hjGo7REQ2uieGLgm9WiRNxfK43tlCCUnDJZC0beauYB1yU8kYjlp3VoCsZcN YC88Es027ik5xHmda8m+v5n77xHeilLmyLUMhfS7Hbeq6VSLaif2npdP0bq0mmm74qVr MJRPsv4qzJ5kkJ8y4U9SLzFhNgbqT/DCjCKYgN9DTS1znsCv+A36PwG0eNidsPSjbCVh 8wuZcPmCdDZaOKQj1op9ndkY8kroQJiN1nCB3Uj1BOKejQwJm/J6VC127Q9/XwJ5/+x2 yrux8qRZpicEZxr+RUhrFA6PvauvF9ei2Y2wqnXmBGfwnwK+ACv66yzeDXzoOIO+fE8y /qrw== X-Gm-Message-State: AOAM532deRuibyg4a7sPiTxdB6UJTbS8w5iF/I0Yp7j6ToS3+Fac38A5 HouWchpwI+ztiP5X9ihqQ4Hc1A== X-Google-Smtp-Source: ABdhPJyLAw11BXqovb/hyRd3O52ps0BA+TwNNEhz5hf8CzWAXREk2pVUIGq9fB6HrslFKPlLwZUkkw== X-Received: by 2002:a17:907:6d25:b0:6f4:d753:f250 with SMTP id sa37-20020a1709076d2500b006f4d753f250mr19240326ejc.580.1652183131282; Tue, 10 May 2022 04:45:31 -0700 (PDT) Received: from cloudflare.com (79.184.139.106.ipv4.supernova.orange.pl. [79.184.139.106]) by smtp.gmail.com with ESMTPSA id n12-20020a1709065e0c00b006f3ef214e0bsm6127841eju.113.2022.05.10.04.45.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 May 2022 04:45:30 -0700 (PDT) References: <20220424154028.1698685-1-xukuohai@huawei.com> <20220424154028.1698685-6-xukuohai@huawei.com> User-agent: mu4e 1.6.10; emacs 27.2 From: Jakub Sitnicki To: Xu Kuohai Cc: bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-kselftest@vger.kernel.org, Catalin Marinas , Will Deacon , Steven Rostedt , Ingo Molnar , Daniel Borkmann , Alexei Starovoitov , Zi Shen Lim , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , "David S . Miller" , Hideaki YOSHIFUJI , David Ahern , Thomas Gleixner , Borislav Petkov , Dave Hansen , x86@kernel.org, hpa@zytor.com, Shuah Khan , Jakub Kicinski , Jesper Dangaard Brouer , Mark Rutland , Pasha Tatashin , Ard Biesheuvel , Daniel Kiss , Steven Price , Sudeep Holla , Marc Zyngier , Peter Collingbourne , Mark Brown , Delyan Kratunov , Kumar Kartikeya Dwivedi Subject: Re: [PATCH bpf-next v3 5/7] bpf, arm64: Support to poke bpf prog Date: Tue, 10 May 2022 11:36:59 +0200 In-reply-to: <20220424154028.1698685-6-xukuohai@huawei.com> Message-ID: <87ilqdobl1.fsf@cloudflare.com> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Thanks for incorporating the attach to BPF progs bits into the series. I have a couple minor comments. Please see below. On Sun, Apr 24, 2022 at 11:40 AM -04, Xu Kuohai wrote: > 1. Set up the bpf prog entry in the same way as fentry to support > trampoline. Now bpf prog entry looks like this: > > bti c // if BTI enabled > mov x9, x30 // save lr > nop // to be replaced with jump instruction > paciasp // if PAC enabled > > 2. Update bpf_arch_text_poke() to poke bpf prog. If the instruction > to be poked is bpf prog's first instruction, skip to the nop > instruction in the prog entry. > > Signed-off-by: Xu Kuohai > --- > arch/arm64/net/bpf_jit.h | 1 + > arch/arm64/net/bpf_jit_comp.c | 41 +++++++++++++++++++++++++++-------- > 2 files changed, 33 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/net/bpf_jit.h b/arch/arm64/net/bpf_jit.h > index 194c95ccc1cf..1c4b0075a3e2 100644 > --- a/arch/arm64/net/bpf_jit.h > +++ b/arch/arm64/net/bpf_jit.h > @@ -270,6 +270,7 @@ > #define A64_BTI_C A64_HINT(AARCH64_INSN_HINT_BTIC) > #define A64_BTI_J A64_HINT(AARCH64_INSN_HINT_BTIJ) > #define A64_BTI_JC A64_HINT(AARCH64_INSN_HINT_BTIJC) > +#define A64_NOP A64_HINT(AARCH64_INSN_HINT_NOP) > > /* DMB */ > #define A64_DMB_ISH aarch64_insn_gen_dmb(AARCH64_INSN_MB_ISH) > diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c > index 3f9bdfec54c4..293bdefc5d0c 100644 > --- a/arch/arm64/net/bpf_jit_comp.c > +++ b/arch/arm64/net/bpf_jit_comp.c > @@ -237,14 +237,23 @@ static bool is_lsi_offset(int offset, int scale) > return true; > } > > -/* Tail call offset to jump into */ > -#if IS_ENABLED(CONFIG_ARM64_BTI_KERNEL) || \ > - IS_ENABLED(CONFIG_ARM64_PTR_AUTH_KERNEL) > -#define PROLOGUE_OFFSET 9 > +#if IS_ENABLED(CONFIG_ARM64_BTI_KERNEL) > +#define BTI_INSNS 1 > +#else > +#define BTI_INSNS 0 > +#endif > + > +#if IS_ENABLED(CONFIG_ARM64_PTR_AUTH_KERNEL) > +#define PAC_INSNS 1 > #else > -#define PROLOGUE_OFFSET 8 > +#define PAC_INSNS 0 > #endif Above can be folded into: #define BTI_INSNS (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL) ? 1 : 0) #define PAC_INSNS (IS_ENABLED(CONFIG_ARM64_PTR_AUTH_KERNEL) ? 1 : 0) > > +/* Tail call offset to jump into */ > +#define PROLOGUE_OFFSET (BTI_INSNS + 2 + PAC_INSNS + 8) > +/* Offset of nop instruction in bpf prog entry to be poked */ > +#define POKE_OFFSET (BTI_INSNS + 1) > + > static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf) > { > const struct bpf_prog *prog = ctx->prog; > @@ -281,12 +290,15 @@ static int build_prologue(struct jit_ctx *ctx, bool ebpf_from_cbpf) > * > */ > > + if (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL)) > + emit(A64_BTI_C, ctx); I'm no arm64 expert, but this looks like a fix for BTI. Currently we never emit BTI because ARM64_BTI_KERNEL depends on ARM64_PTR_AUTH_KERNEL, while BTI must be the first instruction for the jump target [1]. Am I following correctly? [1] https://lwn.net/Articles/804982/ > + > + emit(A64_MOV(1, A64_R(9), A64_LR), ctx); > + emit(A64_NOP, ctx); > + > /* Sign lr */ > if (IS_ENABLED(CONFIG_ARM64_PTR_AUTH_KERNEL)) > emit(A64_PACIASP, ctx); > - /* BTI landing pad */ > - else if (IS_ENABLED(CONFIG_ARM64_BTI_KERNEL)) > - emit(A64_BTI_C, ctx); > > /* Save FP and LR registers to stay align with ARM64 AAPCS */ > emit(A64_PUSH(A64_FP, A64_LR, A64_SP), ctx); > @@ -1552,9 +1564,11 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type poke_type, > u32 old_insn; > u32 new_insn; > u32 replaced; > + unsigned long offset = ~0UL; > enum aarch64_insn_branch_type branch_type; > + char namebuf[KSYM_NAME_LEN]; > > - if (!is_bpf_text_address((long)ip)) > + if (!__bpf_address_lookup((unsigned long)ip, NULL, &offset, namebuf)) > /* Only poking bpf text is supported. Since kernel function > * entry is set up by ftrace, we reply on ftrace to poke kernel > * functions. For kernel funcitons, bpf_arch_text_poke() is only > @@ -1565,6 +1579,15 @@ int bpf_arch_text_poke(void *ip, enum bpf_text_poke_type poke_type, > */ > return -EINVAL; > > + /* bpf entry */ > + if (offset == 0UL) > + /* skip to the nop instruction in bpf prog entry: > + * bti c // if BTI enabled > + * mov x9, x30 > + * nop > + */ > + ip = (u32 *)ip + POKE_OFFSET; This is very much personal preference, however, I find the use pointer arithmetic too clever here. Would go for a more verbose: offset = POKE_OFFSET * AARCH64_INSN_SIZE; ip = (void *)((unsigned long)ip + offset); > + > if (poke_type == BPF_MOD_CALL) > branch_type = AARCH64_INSN_BRANCH_LINK; > else I think it'd make more sense to merge this patch with patch 4 (the preceding one). Initial implementation of of bpf_arch_text_poke() from patch 4 is not fully functional, as it will always fail for bpf_arch_text_poke(ip, BPF_MOD_CALL, ...) calls. At least, I find it a bit confusing. Otherwise than that: Reviewed-by: Jakub Sitnicki