Okay Kees. I will take a look at it.
Best,
Shubham Bansal
On Fri, Jul 7, 2017 at 10:12 AM, Kees Cook wrote:
> On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal
> wrote:
>> Hi Kees,
>>
>> Problem is my ARM machine don't have clang and iproute2 which is
>> keeping me from testing the bpf tail calls.
On Wed, Jul 5, 2017 at 8:49 PM, Shubham Bansal
wrote:
> Hi Kees,
>
> Problem is my ARM machine don't have clang and iproute2 which is
> keeping me from testing the bpf tail calls.
>
> You should do the following to test it,.
>
> 1. tools/testing/selftests/bpf/
> 2. make
> 3. sudo ./test_progs
>
>
Hi Kees,
Problem is my ARM machine don't have clang and iproute2 which is
keeping me from testing the bpf tail calls.
You should do the following to test it,.
1. tools/testing/selftests/bpf/
2. make
3. sudo ./test_progs
And, before testing, you have to do "make headers_install".
These tests are
On Wed, Jul 5, 2017 at 3:11 PM, Kees Cook wrote:
> On Fri, Jun 23, 2017 at 3:39 PM, Shubham Bansal
> wrote:
>> Hi Russell,Daniel and Kees,
>>
>> I am attaching the latest patch with this mail. It included support
>> for BPF_CALL | BPF_JMP tested with and without constant blinding on
>> ARMv7 mach
On Fri, Jun 23, 2017 at 3:39 PM, Shubham Bansal
wrote:
> Hi Russell,Daniel and Kees,
>
> I am attaching the latest patch with this mail. It included support
> for BPF_CALL | BPF_JMP tested with and without constant blinding on
> ARMv7 machine.
> Due to the limitation on my machine I can't test the
Hi Russell,Daniel and Kees,
I am attaching the latest patch with this mail. It included support
for BPF_CALL | BPF_JMP tested with and without constant blinding on
ARMv7 machine.
Due to the limitation on my machine I can't test the tail call. It
would be a great help if any of you could help me wi
On 06/21/2017 09:37 PM, Shubham Bansal wrote:
Hi Daniel,
Good news. Got the CALL to work.
[ 145.670882] test_bpf: Summary: 316 PASSED, 0 FAILED, [287/308 JIT'ed]
Awesome. Do you think with this implementation, the patch could get
accepted? If you think so, then I will send the patch in couple
Hi Daniel,
Good news. Got the CALL to work.
[ 145.670882] test_bpf: Summary: 316 PASSED, 0 FAILED, [287/308 JIT'ed]
Awesome. Do you think with this implementation, the patch could get
accepted? If you think so, then I will send the patch in couple of
days after some refactoring, if not, then do
On 06/21/2017 04:26 PM, Shubham Bansal wrote:
[...]
So ultimately, we call helper_function which takes u64 as arguments
only. I know its asking a lot, but can you please confirm this asap? I
would like to start implementing it.
Yes, that is correct. I think it would be the better, more generic
Hi Daniel,
>
> So my question would be, why can't the JIT imitate something
> similar to what we do in the interpreter as well? So looking
> at the disasm of what gcc compiles for the interpreter when it's
> doing the above call could help as well in going forward. Not
> sure if that answers your
On 06/20/2017 03:34 AM, Shubham Bansal wrote:
Hi Daniel,
Sorry, had a travel over the weekend, so didn't read it in time.
What is the issue with imitating in JIT what the interpreter is
doing as a starting point? That should be generic enough to handle
any case.
Why not proceeding this way f
Hi Daniel,
>
> Sorry, had a travel over the weekend, so didn't read it in time.
>
> What is the issue with imitating in JIT what the interpreter is
> doing as a starting point? That should be generic enough to handle
> any case.
>
> Otherwise you'd need some sort of reverse mapping since verifier
On 06/17/2017 02:23 PM, Shubham Bansal wrote:
Hi Daniel,
Not all of the helpers have 4 or less byte arguments only, there are a
few with 8 byte arguments, so making that general assumption wouldn't
work. I guess what could be done is that helpers have a flag in struct
bpf_func_proto which indic
Hi Daniel,
>
> Not all of the helpers have 4 or less byte arguments only, there are a
> few with 8 byte arguments, so making that general assumption wouldn't
> work. I guess what could be done is that helpers have a flag in struct
> bpf_func_proto which indicates for JITs that all args are 4 byte
On 06/13/2017 08:56 AM, Shubham Bansal wrote:
Hi Daniel, Kees, David, Russel,
Any plans to implement above especially BPF_JMP | BPF_CALL in near future?
Reason why I'm asking is that i) currently the arm32 cBPF JIT implements
all of the cBPF extensions (except SKF_AD_RANDOM and SKF_AD_VLAN_TPID
Hi Daniel, Kees, David, Russel,
>> Any plans to implement above especially BPF_JMP | BPF_CALL in near future?
>> Reason why I'm asking is that i) currently the arm32 cBPF JIT implements
>> all of the cBPF extensions (except SKF_AD_RANDOM and SKF_AD_VLAN_TPID).
>> Some of the programs that were JIT
On 06/12/2017 05:40 PM, Shubham Bansal wrote:
[...]
Did you manage to get tail calls tested as well (I assume so since you
implemented emit_bpf_tail_call() in the patch but just out of curiosity)?
I didn't try it exclusively, I thought test_bpf must have tested it. Doesn't it?
In samples/bpf/
From: Alexander Alemayhu
Date: Tue, 13 Jun 2017 00:45:45 +0200
> On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote:
>>
>> Nope. It looks like a latest addition to testing. Can you please tell
>> me how to test with it?
>>
> cd tools/testing/selftests/bpf/
> make
> sudo ./test_progs
On Mon, Jun 12, 2017 at 09:10:07PM +0530, Shubham Bansal wrote:
>
> Nope. It looks like a latest addition to testing. Can you please tell
> me how to test with it?
>
cd tools/testing/selftests/bpf/
make
sudo ./test_progs
--
Mit freundlichen Grüßen
Alexander Alemayhu
On Mon, Jun 12, 2017 at 3:51 PM, Daniel Borkmann wrote:
> On 05/30/2017 09:19 PM, Kees Cook wrote:
>>> This patch is essentially changing the current implementation of JIT
>>> compiler of Berkeley Packet Filter from classic to internal with almost
>>> all instructions from eBPF ISA supported exce
Hi Russel,
On Mon, Jun 12, 2017 at 4:36 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 12, 2017 at 12:21:03PM +0200, Daniel Borkmann wrote:
>> On 05/30/2017 09:19 PM, Kees Cook wrote:
>> >On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
>> > wrote:
>> >>+static int validate_code(struct jit_ctx
On Mon, Jun 12, 2017 at 12:21:03PM +0200, Daniel Borkmann wrote:
> On 05/30/2017 09:19 PM, Kees Cook wrote:
> >On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
> > wrote:
> >>+static int validate_code(struct jit_ctx *ctx)
> >>+{
> >>+ int i;
> >>+
> >>+ for (i = 0; i < ctx->idx; i++) {
>
On 05/30/2017 09:19 PM, Kees Cook wrote:
Forwarding this to net-dev and eBPF folks, who weren't on CC...
Sorry for being late. Some comments below from a cursory look ...
-Kees
On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
wrote:
The JIT compiler emits ARM 32 bit instructions. Currently,
On Tue, Jun 6, 2017 at 12:47 PM, Shubham Bansal
wrote:
> Hi Russell, Alexei, David, Daniel, kees,
>
> Any update on this patch moving forward?
Since this has gotten testing by various people and passes the
existing self-tests, I think this can probably go in via the ARM patch
tracker? Russell doe
Hi Russell, Alexei, David, Daniel, kees,
Any update on this patch moving forward?
Best,
Shubham Bansal
On Wed, May 31, 2017 at 12:49 AM, Kees Cook wrote:
> Forwarding this to net-dev and eBPF folks, who weren't on CC...
>
> -Kees
>
> On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
> wrote:
>>
Forwarding this to net-dev and eBPF folks, who weren't on CC...
-Kees
On Thu, May 25, 2017 at 4:13 PM, Shubham Bansal
wrote:
> The JIT compiler emits ARM 32 bit instructions. Currently, It supports
> eBPF only. Classic BPF is supported because of the conversion by BPF
> core.
>
> This patch is e
26 matches
Mail list logo
