[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87zgqs8upq.fsf@mpe.ellerman.id.au>
Date: Fri, 29 Oct 2021 12:50:57 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Daniel Borkmann <daniel@...earbox.net>,
"Naveen N. Rao" <naveen.n.rao@...ux.ibm.com>, ast@...nel.org,
christophe.leroy@...roup.eu, Hari Bathini <hbathini@...ux.ibm.com>,
jniethe5@...il.com
Cc: andrii@...nel.org, bpf@...r.kernel.org, john.fastabend@...il.com,
kafai@...com, kpsingh@...nel.org, linuxppc-dev@...ts.ozlabs.org,
netdev@...r.kernel.org, paulus@...ba.org, songliubraving@...com,
stable@...r.kernel.org, yhs@...com
Subject: Re: [PATCH] powerpc/bpf: fix write protecting JIT code
Daniel Borkmann <daniel@...earbox.net> writes:
> On 10/25/21 8:15 AM, Naveen N. Rao wrote:
>> Hari Bathini wrote:
>>> Running program with bpf-to-bpf function calls results in data access
>>> exception (0x300) with the below call trace:
>>>
>>> [c000000000113f28] bpf_int_jit_compile+0x238/0x750 (unreliable)
>>> [c00000000037d2f8] bpf_check+0x2008/0x2710
>>> [c000000000360050] bpf_prog_load+0xb00/0x13a0
>>> [c000000000361d94] __sys_bpf+0x6f4/0x27c0
>>> [c000000000363f0c] sys_bpf+0x2c/0x40
>>> [c000000000032434] system_call_exception+0x164/0x330
>>> [c00000000000c1e8] system_call_vectored_common+0xe8/0x278
>>>
>>> as bpf_int_jit_compile() tries writing to write protected JIT code
>>> location during the extra pass.
>>>
>>> Fix it by holding off write protection of JIT code until the extra
>>> pass, where branch target addresses fixup happens.
>>>
>>> Cc: stable@...r.kernel.org
>>> Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code")
>>> Signed-off-by: Hari Bathini <hbathini@...ux.ibm.com>
>>> ---
>>> arch/powerpc/net/bpf_jit_comp.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Thanks for the fix!
>>
>> Reviewed-by: Naveen N. Rao <naveen.n.rao@...ux.vnet.ibm.com>
>
> LGTM, I presume this fix will be routed via Michael.
Thanks for reviewing, I've picked it up.
> BPF selftests have plenty of BPF-to-BPF calls in there, too bad this was
> caught so late. :/
Yeah :/
STRICT_KERNEL_RWX is not on by default in all our defconfigs, so that's
probably why no one caught it.
I used to run the BPF selftests but they stopped building for me a while
back, I'll see if I can get them going again.
cheers
Powered by blists - more mailing lists