| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20111219151958.GU24496@pengutronix.de> Date: Mon, 19 Dec 2011 16:19:58 +0100 From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de> To: Dave Martin <dave.martin@...aro.org> Cc: Mircea Gherzan <mgherzan@...il.com>, netdev@...r.kernel.org, linux-arm-kernel@...ts.infradead.org Subject: Re: [PATCH v2] ARM: net: JIT compiler for packet filters On Mon, Dec 19, 2011 at 12:50:21PM +0000, Dave Martin wrote: > On Mon, Dec 19, 2011 at 09:40:30AM +0100, Mircea Gherzan wrote: > > Based of Matt Evans's PPC64 implementation. > > > > Supports only ARM mode with EABI. > > > > Supports both little and big endian. Depends on the support for > > unaligned loads on ARMv7. Does not support all the BPF opcodes > > that deal with ancillary data. The scratch memory of the filter > > lives on the stack. > > > > Enabled in the same way as for x86-64 and PPC64: > > > > echo 1 > /proc/sys/net/core/bpf_jit_enable > > > > A value greater than 1 enables opcode output. > > > > Signed-off-by: Mircea Gherzan <mgherzan@...il.com> > > --- > > Interesting patch... I haven't reviewed in detail, but I have a few > quick comments. > > > > > Changes in v2: > > * enable the compiler ony for ARMv5+ because of the BLX instruction > > * use the same comparison for the ARM version checks > > * use misaligned accesses on ARMv6 > > You probably want to change the commit message now to reflect this. > > > * fix the SEEN_MEM > > * fix the mem_words_used() > > > > arch/arm/Kconfig | 1 + > > arch/arm/Makefile | 1 + > > arch/arm/net/Makefile | 3 + > > arch/arm/net/bpf_jit_32.c | 838 +++++++++++++++++++++++++++++++++++++++++++++ > > arch/arm/net/bpf_jit_32.h | 174 ++++++++++ > > 5 files changed, 1017 insertions(+), 0 deletions(-) > > create mode 100644 arch/arm/net/Makefile > > create mode 100644 arch/arm/net/bpf_jit_32.c > > create mode 100644 arch/arm/net/bpf_jit_32.h > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index abba5b8..ea65c41 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -30,6 +30,7 @@ config ARM > > select HAVE_SPARSE_IRQ > > select GENERIC_IRQ_SHOW > > select CPU_PM if (SUSPEND || CPU_IDLE) > > + select HAVE_BPF_JIT if (!THUMB2_KERNEL && AEABI) > > Have to tried your code with a Thumb-2 kernel? > > Quickly skimming though your patch, I don't see an obvious reason why we > can't have that working, though I haven't tried it yet. > > Note that it's fine to have the JIT generating ARM code, even if the rest > if the kernel is Thumb-2. This would only start to cause problems if we > want to do things like set kprobes in the JITted code, or unwind out of > the JITted code. or use a CPU that doesn't speak ARM (e.g. v7M) > It's just necessary to make sure that calls/returns into/out of the > JITted code are handled correctly. You don't seem to do any scary > arithmetic or mov to or from pc or lr, and it doesn't look like you ever > call back into the kernel from JITted code, so the implementation is > probably safe for ARM/Thumb interworking already (if I've understood > correctly). > > It doesn't look hard to port the JIT to generate Thumb-2 code directly > either -- but I suggest not to worry about that initially. So long as > the ARM-based JIT works in a Thumb-2 kernel, it will be useful. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists