From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org, Paul Burton <paulburton@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Hassan Naveed <hnaveed@wavecomp.com>,
Tony Ambardar <itugrok@yahoo.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-mips@vger.kernel.org
Subject: [PATCH 5.4 076/191] MIPS: BPF: Disable MIPS32 eBPF JIT
Date: Tue, 7 Jan 2020 21:53:16 +0100 [thread overview]
Message-ID: <20200107205337.048444554@linuxfoundation.org> (raw)
In-Reply-To: <20200107205332.984228665@linuxfoundation.org>
From: Paul Burton <paulburton@kernel.org>
commit f8fffebdea752a25757b906f3dffecf1a59a6194 upstream.
Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32
architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has
previously only been availailable for MIPS64. It was my understanding at
the time that the BPF test suite was passing & JITing a comparable
number of tests to our cBPF JIT [1], but it turns out that was not the
case.
The eBPF JIT has a number of problems on MIPS32:
- Most notably various code paths still result in emission of MIPS64
instructions which will cause reserved instruction exceptions & kernel
panics when run on MIPS32 CPUs.
- The eBPF JIT doesn't account for differences between the O32 ABI used
by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably
arguments beyond the first 4 are passed on the stack in O32, and this
is entirely unhandled when JITing a BPF_CALL instruction. Stack space
must be reserved for arguments even if they all fit in registers, and
the callee is free to assume that stack space has been reserved for
its use - with the eBPF JIT this is not the case, so calling any
function can result in clobbering values on the stack & unpredictable
behaviour. Function arguments in eBPF are always 64-bit values which
is also entirely unhandled - the JIT still uses a single (32-bit)
register per argument. As a result all function arguments are always
passed incorrectly when JITing a BPF_CALL instruction, leading to
kernel crashes or strange behavior.
- The JIT attempts to bail our on use of ALU64 instructions or 64-bit
memory access instructions. The code doing this at the start of
build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW,
when it should really be checking BPF_SIZE() & only doing so when
BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false
positives that cause more bailouts than intended, and that in turns
hides some of the problems described above.
- The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF
instructions that the MIPS32 eBPF JIT bails out on, leading to most
cBPF programs not being JITed at all.
Until these problems are resolved, revert the enabling of the eBPF JIT
on MIPS32 done by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support
for MIPS32 architecture.").
Note that this does not undo the changes made to the eBPF JIT by that
commit, since they are a useful starting point to providing MIPS32
support - they're just not nearly complete.
[1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/
Signed-off-by: Paul Burton <paulburton@kernel.org>
Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.")
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Hassan Naveed <hnaveed@wavecomp.com>
Cc: Tony Ambardar <itugrok@yahoo.com>
Cc: bpf@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: <stable@vger.kernel.org> # v5.2+
Cc: linux-mips@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/mips/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -46,7 +46,7 @@ config MIPS
select HAVE_ARCH_TRACEHOOK
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if CPU_SUPPORTS_HUGEPAGES
select HAVE_ASM_MODVERSIONS
- select HAVE_EBPF_JIT if (!CPU_MICROMIPS)
+ select HAVE_EBPF_JIT if (64BIT && !CPU_MICROMIPS)
select HAVE_CONTEXT_TRACKING
select HAVE_COPY_THREAD_TLS
select HAVE_C_RECORDMCOUNT
next parent reply other threads:[~2020-01-07 21:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200107205332.984228665@linuxfoundation.org>
2020-01-07 20:53 ` Greg Kroah-Hartman [this message]
2020-01-07 20:53 ` [PATCH 5.4 077/191] MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in Kconfig Greg Kroah-Hartman
2020-01-07 20:53 ` [PATCH 5.4 078/191] MIPS: Avoid VDSO ABI breakage due to global register variable Greg Kroah-Hartman
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=20200107205337.048444554@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=hnaveed@wavecomp.com \
--cc=itugrok@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulburton@kernel.org \
--cc=stable@vger.kernel.org \
/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).