From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Hari Bathini <hbathini@linux.ibm.com>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Song Liu <songliubraving@fb.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>
Subject: Re: [RFC PATCH 0/3] enable bpf_prog_pack allocator for powerpc
Date: Thu, 17 Nov 2022 06:59:09 +0000 [thread overview]
Message-ID: <02496f7a-51d8-4fc0-161d-b29d5e657089@csgroup.eu> (raw)
In-Reply-To: <6151f5c6-2e64-5f2d-01b1-6f517f4301c0@linux.ibm.com>
Le 16/11/2022 à 18:01, Hari Bathini a écrit :
>
>
> On 16/11/22 12:14 am, Christophe Leroy wrote:
>>
>>
>> Le 14/11/2022 à 18:27, Christophe Leroy a écrit :
>>>
>>>
>>> Le 14/11/2022 à 15:47, Hari Bathini a écrit :
>>>> Hi Christophe,
>>>>
>>>> On 11/11/22 4:55 pm, Christophe Leroy wrote:
>>>>> Le 10/11/2022 à 19:43, Hari Bathini a écrit :
>>>>>> Most BPF programs are small, but they consume a page each. For
>>>>>> systems
>>>>>> with busy traffic and many BPF programs, this may also add
>>>>>> significant
>>>>>> pressure on instruction TLB. High iTLB pressure usually slows down
>>>>>> the
>>>>>> whole system causing visible performance degradation for production
>>>>>> workloads.
>>>>>>
>>>>>> bpf_prog_pack, a customized allocator that packs multiple bpf
>>>>>> programs
>>>>>> into preallocated memory chunks, was proposed [1] to address it. This
>>>>>> series extends this support on powerpc.
>>>>>>
>>>>>> Patches 1 & 2 add the arch specific functions needed to support this
>>>>>> feature. Patch 3 enables the support for powerpc. The last patch
>>>>>> ensures cleanup is handled racefully.
>>>>>>
>>>>
>>>>>> Tested the changes successfully on a PowerVM. patch_instruction(),
>>>>>> needed for bpf_arch_text_copy(), is failing for ppc32. Debugging it.
>>>>>> Posting the patches in the meanwhile for feedback on these changes.
>>>>>
>>>>> I did a quick test on ppc32, I don't get such a problem, only
>>>>> something
>>>>> wrong in the dump print as traps intructions only are dumped, but
>>>>> tcpdump works as expected:
>>>>
>>>> Thanks for the quick test. Could you please share the config you used.
>>>> I am probably missing a few knobs in my conifg...
>>>>
>>>
>>
>> I also managed to test it on QEMU. The config is based on
>> pmac32_defconfig.
>
> I had the same config but hit this problem:
>
> # echo 1 > /proc/sys/net/core/bpf_jit_enable; modprobe test_bpf
> test_bpf: #0 TAX
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 96 at arch/powerpc/net/bpf_jit_comp.c:367
> bpf_int_jit_compile+0x8a0/0x9f8
I get no such problem, on QEMU, and I checked the .config has:
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_STRICT_MODULE_RWX=y
Boot successful.
/ # ifconfig eth0 10.0.2.15
e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
/ # tftp -g 10.0.2.2 -r test_bpf.ko
/ # echo 1 > /proc/sys/net/core/bpf_jit_enable
/ # insmod ./test_bpf.ko
test_bpf: #0 TAX jited:1 216 87 86 PASS
test_bpf: #1 TXA jited:1 57 27 27 PASS
test_bpf: #2 ADD_SUB_MUL_K jited:1 50 PASS
test_bpf: #3 DIV_MOD_KX jited:1 110 PASS
test_bpf: #4 AND_OR_LSH_K jited:1 67 26 PASS
test_bpf: #5 LD_IMM_0 jited:1 77 PASS
...
By the way, you can note that during the boot you get:
This platform has HASH MMU, STRICT_MODULE_RWX won't work
See why in 0670010f3b10 ("powerpc/32s: Enable STRICT_MODULE_RWX for the
603 core")
Nevertheless it should prevent patch_instruction() to work.
Could you had a pr_err() in __patch_instruction() in the failure path to
print and check exec_addr and patch_addr ?
> jited:1
> kernel tried to execute exec-protected page (be857020) - exploit
> attempt? (uid: 0)
> BUG: Unable to handle kernel instruction fetch
> Faulting instruction address: 0xbe857020
I'm a bit surprised of this. On hash based book3s/32 there is no way to
protect pages for exec-protection. Protection is performed at segment
level, all kernel segments have the NX bit set except the segment used
for module text, which is by default 0xb0000000-0xbfffffff.
Or maybe this is the first time that address is accessed, and the ISI
handler does the check before loading the hash table ?
>
> bpf_jit_binary_pack_finalize() function failed due to
> patch_instruction() ..
Is there a way tell BPF core that jit failed in that case to avoid that ?
Christophe
next prev parent reply other threads:[~2022-11-17 6:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-10 18:43 [RFC PATCH 0/3] enable bpf_prog_pack allocator for powerpc Hari Bathini
2022-11-10 18:43 ` [RFC PATCH 1/3] powerpc/bpf: implement bpf_arch_text_copy Hari Bathini
2022-11-13 13:17 ` Christophe Leroy
2022-11-14 14:54 ` Hari Bathini
2022-11-10 18:43 ` [RFC PATCH 2/3] powerpc/bpf: implement bpf_arch_text_invalidate for bpf_prog_pack Hari Bathini
2022-11-13 18:00 ` Christophe Leroy
2022-11-10 18:43 ` [RFC PATCH 3/3] powerpc/bpf: use bpf_jit_binary_pack_[alloc|finalize|free] Hari Bathini
2022-11-13 18:36 ` Christophe Leroy
2022-11-11 11:25 ` [RFC PATCH 0/3] enable bpf_prog_pack allocator for powerpc Christophe Leroy
2022-11-14 14:47 ` Hari Bathini
[not found] ` <bf0af91e-861c-1608-7150-d31578be9b02@csgroup.eu>
[not found] ` <e0266414-843f-db48-a56d-1d8a8944726a@csgroup.eu>
2022-11-16 17:01 ` Hari Bathini
2022-11-16 17:16 ` Christophe Leroy
2022-11-17 6:59 ` Christophe Leroy [this message]
2022-11-18 8:39 ` Hari Bathini
2022-11-18 8:51 ` Christophe Leroy
2022-11-18 9:39 ` Hari Bathini
2022-11-18 11:46 ` Christophe Leroy
2022-11-18 17:28 ` Song Liu
2022-11-18 18:05 ` Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02496f7a-51d8-4fc0-161d-b29d5e657089@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hbathini@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=naveen.n.rao@linux.ibm.com \
--cc=songliubraving@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).