On Tue, May 23, 2017 at 11:39 AM, Shubham Bansal
wrote:
> Here is the patch I sent to the arm mailing list.
Thanks for sending this!
I'm trying to figure out the best way to split this up, but the bulk
of it (the actual JIT changes) seems like they need to all land at the
same time. Any thoughts
Hi Kees, Daniel, Mircea and David,
Here is the patch I sent to the arm mailing list.
Any Comments are welcome.
-- Forwarded message --
From: Shubham Bansal
Date: Wed, May 24, 2017 at 12:03 AM
Subject: [PATCH] RFC: arm: eBPF JIT compiler
To: li...@armlinux.org.uk
Cc: linux-arm-ker
On Mon, May 22, 2017 at 10:03 PM, Shubham Bansal
wrote:
> On Tue, May 23, 2017 at 9:52 AM, Kees Cook wrote:
>> On Mon, May 22, 2017 at 8:34 PM, Shubham Bansal
>> wrote:
>>> I would post them as soon as I test them on ARMv5 and ARMv6. If you
>>> can help me with that, please let me know.
>>
>> Pl
Hi Kees,
I already have ARMv5 and ARMv6 code written. I just haven't tested it
yet. Should i send the patch with those as well ?
Best,
Shubham Bansal
On Tue, May 23, 2017 at 9:52 AM, Kees Cook wrote:
> On Mon, May 22, 2017 at 8:34 PM, Shubham Bansal
> wrote:
>> I would post them as soon as I
On Mon, May 22, 2017 at 7:58 PM, Shubham Bansal
wrote:
> On testing the eBPF JIT with CONFIG_FRAME_POINTER I got the following
> crash for non jitted testcase.
It's just a softlockup WARN, not a crash, and I think it'd to be
expected given the large runtime test_bpf reports:
> [ 72.032494] tes
On Mon, May 22, 2017 at 8:34 PM, Shubham Bansal
wrote:
> I would post them as soon as I test them on ARMv5 and ARMv6. If you
> can help me with that, please let me know.
Please post what you have: it would be better to see what you've got
now in case additional changes are needed so you don't hav
Hi Florian,
>> I think it is fine to only target ARMv7. It is harder and harder to
>> find devices on v5 or v6 CPUs that would want to be using BPF JIT,
>> IMO.
>
> There are still a ton of Marvell-based routers out there (e.g: Kirkwood,
> Orion5x) that are ARMv5 and that prompted Nicholas (hey th
Hi,
On testing the eBPF JIT with CONFIG_FRAME_POINTER I got the following
crash for non jitted testcase.
[ 72.032494] test_bpf: #267 BPF_MAXINSNS: Call heavy transformations
jited:0 1112799
[ 92.304815] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s!
[insmod:104]
[ 92.305050] Modules
On Mon, May 22, 2017 at 10:04 AM, Shubham Bansal
wrote:
> These all benchmarks are for ARMv7.
Thanks! In the future, try to avoid the white-space damage
(line-wrapping). And it looks like you've still got debugging turned
on in your jit code:
[ 56.176033] test_bpf: #21 LD_CPU
[ 56.176329] bp
On 05/22/2017 11:58 AM, Kees Cook wrote:
> On Sat, May 20, 2017 at 1:01 PM, Shubham Bansal
> wrote:
>> Hi Daniel and Kees,
>>
>> Before I send the patch, I have tested the JIT compiler on ARMv7 but
>> not on ARMv5 or ARMv6. So can you tell me which arch versions I should
>> test it for?
>> Also fo
On Sat, May 20, 2017 at 1:01 PM, Shubham Bansal
wrote:
> Hi Daniel and Kees,
>
> Before I send the patch, I have tested the JIT compiler on ARMv7 but
> not on ARMv5 or ARMv6. So can you tell me which arch versions I should
> test it for?
> Also for my testing, CONFIG_FRAME_POINTER and CONFIG_CPU_B
Hi Daniel,
Here are the benchmarks.
1) Interpreter:
[root@vexpress modules]# insmod test_bpf.ko
[ 37.244999] test_bpf: #0 TAX jited:0 757 645 650 PASS
[ 37.272577] test_bpf: #1 TXA jited:0 366 334 336 PASS
[ 37.283507] test_bpf: #2 ADD_SUB_MUL_K jited:0 543 PASS
[ 37.289542] test_bpf: #3
On 05/20/2017 10:01 PM, Shubham Bansal wrote:
[...]
Before I send the patch, I have tested the JIT compiler on ARMv7 but
not on ARMv5 or ARMv6. So can you tell me which arch versions I should
test it for?
Also for my testing, CONFIG_FRAME_POINTER and CONFIG_CPU_BIG_ENDIAN
are both disabled. But I
Hi Daniel and Kees,
Before I send the patch, I have tested the JIT compiler on ARMv7 but
not on ARMv5 or ARMv6. So can you tell me which arch versions I should
test it for?
Also for my testing, CONFIG_FRAME_POINTER and CONFIG_CPU_BIG_ENDIAN
are both disabled. But I need to test JIT with these flag
On 05/13/2017 11:38 PM, Shubham Bansal wrote:
Finally finished testing.
"test_bpf: Summary: 314 PASSED, 0 FAILED, [274/306 JIT'ed]"
What are the missing pieces and how is the performance compared
to the interpreter?
Thanks,
Daniel
On Sat, May 13, 2017 at 2:38 PM, Shubham Bansal
wrote:
> Finally finished testing.
>
> "test_bpf: Summary: 314 PASSED, 0 FAILED, [274/306 JIT'ed]"
Nice work! Glad you've been chipping away at this. Thanks!
-Kees
>
> Will send the patch after code refactoring. Thanks for all the help
> you guys.
Finally finished testing.
"test_bpf: Summary: 314 PASSED, 0 FAILED, [274/306 JIT'ed]"
Will send the patch after code refactoring. Thanks for all the help
you guys. I really really appreciate it.
Special thanks to Kees and Daniel. :)
Best,
Shubham Bansal
On Thu, May 11, 2017 at 9:00 PM, Kees C
On Thu, May 11, 2017 at 2:32 AM, Shubham Bansal
wrote:
> What do you guys suggest i should implement it? I am almost done with
> my current implementation but if you think I should change it to the
> way David suggested, its better to suggest now before I send the
> patch.
I'd say send what you h
Hi kees & Daniel,
David suggested following :
"""
eBPF has registers 0 through 10 plus you need to allocate another
temporary register for constant blinding (this is BPF_REG_AX).
I would put all of BPF_REG_0 through BPF_REG_5 in registers if
possible. BPF_REG_FP is the frame pointer which you d
On 05/09/2017 10:12 PM, Shubham Bansal wrote:
Hi Daniel,
I just tried running test_bpf.ko module.
$ echo 2 >> /proc/sys/net/core/bpf_jit_enable
$ insmod test_bpf.ko
test_bpf: #0 TAX
bpf_jit: flen=14 proglen=212 pass=2 image=7f15a83c from=insmod pid=730
JIT code: : f0 05 2d e9 40 d2 4d
From: Shubham Bansal
Date: Wed, 10 May 2017 01:42:10 +0530
> Why is trying to execute TAX which is a cBPF instruction?
Because some of the tests are classic BPF programs which
get translated into eBPF ones and sent to the JIT for
compilation.
Hi Daniel,
I just tried running test_bpf.ko module.
$ echo 2 >> /proc/sys/net/core/bpf_jit_enable
$ insmod test_bpf.ko
test_bpf: #0 TAX
bpf_jit: flen=14 proglen=212 pass=2 image=7f15a83c from=insmod pid=730
JIT code: : f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
JIT code: 0010:
Okay. My mistake. I just checked the verify function.
Apologies.
Best,
Shubham Bansal
On Sun, May 7, 2017 at 1:57 AM, Shubham Bansal
wrote:
> Thanks David.
>
> Hi all,
>
> I have two questions about the code at arch/arm64/net/bpf_jit_comp.c.
>
> 1. At line 708, " const u8 r1 = bpf2a64[BPF_REG_1
Thanks David.
Hi all,
I have two questions about the code at arch/arm64/net/bpf_jit_comp.c.
1. At line 708, " const u8 r1 = bpf2a64[BPF_REG_1]; /* r1: struct
sk_buff *skb */ ".
Why is this code using BPF_REG_1 before saving it? As far as I
know, BPF_REG_1 has pointer to bpf program context a
From: Shubham Bansal
Date: Sat, 6 May 2017 22:18:16 +0530
> Hi Daniel,
>
> Thanks for the last reply about the testing of eBPF JIT.
>
> I have one issue though, I am not able to find what BPF_ABS and
> BPF_IND instruction does exactly.
They are not instructions, they are modifiers for the BPF_
Hi Daniel,
Thanks for the last reply about the testing of eBPF JIT.
I have one issue though, I am not able to find what BPF_ABS and
BPF_IND instruction does exactly. It not described on this link -
https://www.kernel.org/doc/Documentation/networking/filter.txt either.
Can you please tell me where
On 04/06/2017 01:05 PM, Shubham Bansal wrote:
Gentle Reminder.
Sorry for late reply.
Anybody can tell me how to test the JIT compiler ?
There's lib/test_bpf.c, see Documentation/networking/filter.txt +1349
for some more information. It basically contains various test cases that
have the pur
Gentle Reminder.
Anybody can tell me how to test the JIT compiler ?
Best,
Shubham Bansal
On Thu, Mar 30, 2017 at 7:34 PM, Shubham Bansal
wrote:
> Thanks Daniel.
>
> Can you tell me how to test the eBPF JIT compiler? It would be great
> if you could tell me starting from compiling to proper test
Thanks Daniel.
Can you tell me how to test the eBPF JIT compiler? It would be great
if you could tell me starting from compiling to proper testing.
Best,
Shubham Bansal
On Wed, Mar 29, 2017 at 5:30 AM, Daniel Borkmann wrote:
> Hi Shubham,
>
> On 03/28/2017 10:49 PM, Shubham Bansal wrote:
> [...
Hi Shubham,
On 03/28/2017 10:49 PM, Shubham Bansal wrote:
[...]
Do you have any document to understand the working of tail calls? I
looked at your presentations but it seemed confusing to me. Anything
simple would be great, just about the tail calls. I don't think I need
examples, I can get them
Thanks David. It helped a lot.
Hi Daniel,
Do you have any document to understand the working of tail calls? I
looked at your presentations but it seemed confusing to me. Anything
simple would be great, just about the tail calls. I don't think I need
examples, I can get them from your presentation
From: Shubham Bansal
Date: Wed, 15 Mar 2017 17:43:44 +0530
>> You can't truncate, but you'll have to build 64-bit ops using 32-bit
>> registers.
>
> A small example would help a lot.
You can simply perform 64-bit operations in C code and see what gcc
outputs for that code on this 32-bit target
Hi kees,
> It seems like you're suggesting truncating the 64-bit register values?
> I think your best solution is going to be to use a memory scratch
> space and build 64-bit operations using 32-bit registers and memory
> operations.
Yes. I was suggesting the truncating of 64-bit register values,
On Wed, Feb 1, 2017 at 5:01 AM, Shubham Bansal
wrote:
> Hi Kees & Daniel,
>
> On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
>> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
>> >> > registers with 32 bit arm registers which looks wrong to me. Do anybody
>>
Anybody willing to take swing at my following comments ?
On Wed, Feb 1, 2017 at 6:31 PM, Shubham Bansal
wrote:
> Hi Kees & Daniel,
>
> On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
>> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
>> >> > registers with 3
Gentle reminder.
Hi Kees & Daniel,
On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
> >> > registers with 32 bit arm registers which looks wrong to me. Do anybody
> >> > have some idea about how to map eBPF->a
> On Feb 2, 2017, at 11:04 PM, Shubham Bansal wrote:
>
> Hi Nick,
>
> On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
> wrote:
>> Hey Shubham,
>>
>> I have been doing some similar work-might be worth pooling
>> resource if there is interest?
>
> Sure. That sounds great.
>
>>
>> We made a pr
Hi Nick,
On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
wrote:
> Hey Shubham,
>
> I have been doing some similar work-might be worth pooling
> resource if there is interest?
Sure. That sounds great.
>
> We made a presentation at the previous netdev conference about
> what we are doing-you can ch
Resending because of Formatting problems.
Hi Kees & Daniel,
On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
> >> > registers with 32 bit arm registers which looks wrong to me. Do anybody
> >> > have some idea
Hi Kees & Daniel,
On Tue, Jan 31, 2017 at 09:44:56AM -0800, Kees Cook wrote:
> >> > 1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
> >> > registers with 32 bit arm registers which looks wrong to me. Do anybody
> >> > have some idea about how to map eBPF->arm 32 bit register
On Mon, Jan 30, 2017 at 2:38 AM, Shubham Bansal
wrote:
> Hi all,
>
> Please ignore last copy of this mail. Kernel mailing lists bounced my
> last mail back because of HTML content.
>
> Just starting a new thread with proper heading on the main kernel
> hardening and net-dev mailing list so that ot
Hi all,
Please ignore last copy of this mail. Kernel mailing lists bounced my
last mail back because of HTML content.
Just starting a new thread with proper heading on the main kernel
hardening and net-dev mailing list so that other people can be involved
in this. Please don't take this as a pers
42 matches
Mail list logo
