Daniel Borkmann <dan...@iogearbox.net> writes: > On 02/21/2018 01:33 AM, Michael Ellerman wrote: >> Mark Lord <ml...@pobox.com> writes: >> >>> I am using SECCOMP to filter syscalls on a ppc32 platform, >>> and noticed that the JIT compiler was failing on the BPF >>> even though the interpreter was working fine. >>> >>> The issue was that the compiler was missing one of the instructions >>> used by SECCOMP, so here is a patch to enable JIT for that instruction. >>> >>> Signed-Off-By: Mark Lord <ml...@pobox.com> >> >> Thanks. >> >> What is the failure mode without this patch? I assume when you have the >> JIT enabled the seccomp filter fails to load entirely? Or do we have >> logic to fall back to the interpreter? > > The logic for all JITs is that once a BPF insn cannot be JITed then it falls > back to BPF interpreter. Here, since ppc32 is cBPF the path is: cBPF insn -> > cBPF JIT -> fail -> migrate cBPF to eBPF -> run in eBPF interpreter. In the > case where interpreter is compiled out (CONFIG_BPF_JIT_ALWAYS_ON), then the > filter is rejected.
OK thanks. >> Either way we should probably back port to stable. I assume this has >> been broken since we originally added 32-bit support, so: > > Note that arm32 before it was converted to be an eBPF JIT (eBPF JITs do handle > seccomp BPF in any case) was the only cBPF JIT that had it 'JIT-able', so > currently, other cBPF ones like sparc32 or mips32 don't translate it either. > Meaning, it would be nice to have as feature; I wouldn't necessarily frame > it as a bug though (or at least a stable-urgent one, imho, but I leave that > to you, of course). OK, I'll just add the Fixes tag for our reference and we can always back port it to stable later if we want to. cheers