* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-01 13:01 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-01 13:01 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
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 registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.
I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.
So, What I am thinking is something like this :
- bpf_mov r0(64),r1(64) will be JITed like this :
- ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
- Do MOV ar0(32),ar1(32) as an ARM instruction.
- ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.
- Similarly, For all BPF_ALU class instructions.
- For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
- For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
- For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
- For BPF_DIV, 32 bit masking should be fine, I guess.
- For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
- For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
- For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.
- Although, for ALU instructions, there is a big problem of register
flag manipulations. Generally, architecture's ABI takes care of this
part but as we are doing 64 bit Instructions emulation(kind of) on 32
bit machine, it needs to be done manually. Does that sound correct ?
- I am not JITing BPF_ALU64 class instructions as of now. As we have to
take care of atomic instructions and race conditions with these
instruction which looks complicated to me as of now. Will try to figure out
this part and implement it later. Currently, I will just let it be
interpreted by the ebpf interpreter.
- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
the address pointers on 32 bit arch like arm will be of 32 bit only.
So, for BPF_JMP, masking the 64 bit destination address to 32 bit
should do the trick and no address will be corrupted in this way. Am I
correct to assume this ?
Also, I need to check for address getting out of the allowed memory
range.
- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
assuming the same thing as above - All addresses and pointers are 32
bit - which can be taken care just by maksing the eBPF register
values. Does that sound correct ?
Also, I need to check for the address overflow, address getting out
of the allowed memory range and things like that.
> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.
I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.
> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-01 13:01 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-01 13:01 UTC (permalink / raw)
To: linux-arm-kernel
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 registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.
I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.
So, What I am thinking is something like this :
- bpf_mov r0(64),r1(64) will be JITed like this :
- ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
- Do MOV ar0(32),ar1(32) as an ARM instruction.
- ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.
- Similarly, For all BPF_ALU class instructions.
- For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
- For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
- For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
- For BPF_DIV, 32 bit masking should be fine, I guess.
- For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
- For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
- For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.
- Although, for ALU instructions, there is a big problem of register
flag manipulations. Generally, architecture's ABI takes care of this
part but as we are doing 64 bit Instructions emulation(kind of) on 32
bit machine, it needs to be done manually. Does that sound correct ?
- I am not JITing BPF_ALU64 class instructions as of now. As we have to
take care of atomic instructions and race conditions with these
instruction which looks complicated to me as of now. Will try to figure out
this part and implement it later. Currently, I will just let it be
interpreted by the ebpf interpreter.
- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
the address pointers on 32 bit arch like arm will be of 32 bit only.
So, for BPF_JMP, masking the 64 bit destination address to 32 bit
should do the trick and no address will be corrupted in this way. Am I
correct to assume this ?
Also, I need to check for address getting out of the allowed memory
range.
- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
assuming the same thing as above - All addresses and pointers are 32
bit - which can be taken care just by maksing the eBPF register
values. Does that sound correct ?
Also, I need to check for the address overflow, address getting out
of the allowed memory range and things like that.
> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.
I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.
> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
^ permalink raw reply [flat|nested] 67+ messages in thread
* Fwd: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-02-01 13:01 ` Shubham Bansal
@ 2017-02-01 13:06 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-01 13:06 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
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 about how to map eBPF->arm 32 bit registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.
I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.
So, What I am thinking is something like this :
- bpf_mov r0(64),r1(64) will be JITed like this :
- ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
- Do MOV ar0(32),ar1(32) as an ARM instruction.
- ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.
- Similarly, For all BPF_ALU class instructions.
- For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
- For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
- For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
- For BPF_DIV, 32 bit masking should be fine, I guess.
- For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
- For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
- For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.
- Although, for ALU instructions, there is a big problem of register
flag manipulations. Generally, architecture's ABI takes care of this
part but as we are doing 64 bit Instructions emulation(kind of) on 32
bit machine, it needs to be done manually. Does that sound correct ?
- I am not JITing BPF_ALU64 class instructions as of now. As we have to
take care of atomic instructions and race conditions with these
instruction which looks complicated to me as of now. Will try to figure out
this part and implement it later. Currently, I will just let it be
interpreted by the ebpf interpreter.
- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
the address pointers on 32 bit arch like arm will be of 32 bit only.
So, for BPF_JMP, masking the 64 bit destination address to 32 bit
should do the trick and no address will be corrupted in this way. Am I
correct to assume this ?
Also, I need to check for address getting out of the allowed memory
range.
- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
assuming the same thing as above - All addresses and pointers are 32
bit - which can be taken care just by maksing the eBPF register
values. Does that sound correct ?
Also, I need to check for the address overflow, address getting out
of the allowed memory range and things like that.
> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.
I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.
> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Fwd: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-01 13:06 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-01 13:06 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
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 about how to map eBPF->arm 32 bit registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.
I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.
So, What I am thinking is something like this :
- bpf_mov r0(64),r1(64) will be JITed like this :
- ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
- Do MOV ar0(32),ar1(32) as an ARM instruction.
- ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.
- Similarly, For all BPF_ALU class instructions.
- For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
- For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
- For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
- For BPF_DIV, 32 bit masking should be fine, I guess.
- For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
- For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
- For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.
- Although, for ALU instructions, there is a big problem of register
flag manipulations. Generally, architecture's ABI takes care of this
part but as we are doing 64 bit Instructions emulation(kind of) on 32
bit machine, it needs to be done manually. Does that sound correct ?
- I am not JITing BPF_ALU64 class instructions as of now. As we have to
take care of atomic instructions and race conditions with these
instruction which looks complicated to me as of now. Will try to figure out
this part and implement it later. Currently, I will just let it be
interpreted by the ebpf interpreter.
- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
the address pointers on 32 bit arch like arm will be of 32 bit only.
So, for BPF_JMP, masking the 64 bit destination address to 32 bit
should do the trick and no address will be corrupted in this way. Am I
correct to assume this ?
Also, I need to check for address getting out of the allowed memory
range.
- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
assuming the same thing as above - All addresses and pointers are 32
bit - which can be taken care just by maksing the eBPF register
values. Does that sound correct ?
Also, I need to check for the address overflow, address getting out
of the allowed memory range and things like that.
> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.
I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.
> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
^ permalink raw reply [flat|nested] 67+ messages in thread
* Fwd: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-02-01 13:06 ` [kernel-hardening] " Shubham Bansal
@ 2017-02-06 11:52 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-06 11:52 UTC (permalink / raw)
To: Kees Cook, Daniel Borkmann, Mircea Gherzan
Cc: netdev, kernel-hardening, linux-arm-kernel
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->arm 32 bit registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.
I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.
So, What I am thinking is something like this :
- bpf_mov r0(64),r1(64) will be JITed like this :
- ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
- Do MOV ar0(32),ar1(32) as an ARM instruction.
- ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.
- Similarly, For all BPF_ALU class instructions.
- For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
- For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
- For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
- For BPF_DIV, 32 bit masking should be fine, I guess.
- For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
- For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
- For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.
- Although, for ALU instructions, there is a big problem of register
flag manipulations. Generally, architecture's ABI takes care of this
part but as we are doing 64 bit Instructions emulation(kind of) on 32
bit machine, it needs to be done manually. Does that sound correct ?
- I am not JITing BPF_ALU64 class instructions as of now. As we have to
take care of atomic instructions and race conditions with these
instruction which looks complicated to me as of now. Will try to figure out
this part and implement it later. Currently, I will just let it be
interpreted by the ebpf interpreter.
- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
the address pointers on 32 bit arch like arm will be of 32 bit only.
So, for BPF_JMP, masking the 64 bit destination address to 32 bit
should do the trick and no address will be corrupted in this way. Am I
correct to assume this ?
Also, I need to check for address getting out of the allowed memory
range.
- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
assuming the same thing as above - All addresses and pointers are 32
bit - which can be taken care just by maksing the eBPF register
values. Does that sound correct ?
Also, I need to check for the address overflow, address getting out
of the allowed memory range and things like that.
> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.
I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.
> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Fwd: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-06 11:52 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-06 11:52 UTC (permalink / raw)
To: Kees Cook, Daniel Borkmann, Mircea Gherzan
Cc: netdev, kernel-hardening, linux-arm-kernel
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->arm 32 bit registers ?
> >>
> >> I was going to say "look at the x86 32-bit implementation." ... But
> >> there isn't one. :( I'm going to guess that there isn't a very good
> >> answer here. I assume you'll have to build some kind of stack scratch
> >> space to load/save.
> >
> >
> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
> > think its very difficult to implement it without any complications and
> > errors.
>
> Yeah, that does seem to make it much more difficult.
I was thinking of first implementing only instructions with 32 bit
register operands. It will hugely decrease the surface area of eBPF
instructions that I have to cover for the first patch.
So, What I am thinking is something like this :
- bpf_mov r0(64),r1(64) will be JITed like this :
- ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
bit and store it in arm register(ar1).
- Do MOV ar0(32),ar1(32) as an ARM instruction.
- ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
and store it in 64 bit ebpf register r0.
- Similarly, For all BPF_ALU class instructions.
- For BPF_ADD, I will mask the addition result to 32 bit only.
I am not sure, Overflow might be a problem.
- For BPF_SUB, I will mask the subtraction result to 32 bit only.
I am not sure, Underflow might be problem.
- For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
- For BPF_DIV, 32 bit masking should be fine, I guess.
- For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
masking should be fine.
- For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
- For BPF_END, 32 bit masking should work fine.
Let me know if any of the above point is wrong or need your suggestion.
- Although, for ALU instructions, there is a big problem of register
flag manipulations. Generally, architecture's ABI takes care of this
part but as we are doing 64 bit Instructions emulation(kind of) on 32
bit machine, it needs to be done manually. Does that sound correct ?
- I am not JITing BPF_ALU64 class instructions as of now. As we have to
take care of atomic instructions and race conditions with these
instruction which looks complicated to me as of now. Will try to figure out
this part and implement it later. Currently, I will just let it be
interpreted by the ebpf interpreter.
- For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
the address pointers on 32 bit arch like arm will be of 32 bit only.
So, for BPF_JMP, masking the 64 bit destination address to 32 bit
should do the trick and no address will be corrupted in this way. Am I
correct to assume this ?
Also, I need to check for address getting out of the allowed memory
range.
- For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
assuming the same thing as above - All addresses and pointers are 32
bit - which can be taken care just by maksing the eBPF register
values. Does that sound correct ?
Also, I need to check for the address overflow, address getting out
of the allowed memory range and things like that.
> > Do you have any code references for me to take a look? Otherwise, I think
> > its not possible for me to implement it without using any reference.
>
> I don't know anything else, no.
I think, I will give it a try. Otherwise, my last 1 month which I used
to read about eBPF, eBPF linux code and arm32 ABI would be a complete
waste.
> >>
> >>
> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
> >> > ?
> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> >> > its instructions with native instructions.
> >>
> >> I don't know -- it might be tricky with needing to deal with 64-bit
> >> registers. But if you can make it faster than the non-JIT, it should
> >> be a win. :) Yay assembly.
Well, As I mentioned above about my thinking towards the implementation,
I am not sure it would be faster than non-JIT or even correct for that matter.
It might be but I don't think I have enough knowledge to benchmark the
implementation as of now.
-Shubham Bansal
^ permalink raw reply [flat|nested] 67+ messages in thread
[parent not found: <76621BFF-B30B-4417-AB2B-DB21CA6092D9@netronome.com>]
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
[not found] ` <76621BFF-B30B-4417-AB2B-DB21CA6092D9@netronome.com>
2017-02-03 7:04 ` Shubham Bansal
@ 2017-02-03 7:04 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-03 7:04 UTC (permalink / raw)
To: nick viljoen, Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
Hi Nick,
On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
<nick.viljoen@netronome.com> 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 check it out here :)
>
> https://www.youtube.com/watch?v=-5BzT1ch19s&t=45s
Sorry for the late reply. I had to watch the whole video. Its was fun.
Now. Its seems like a small of your complete project was related to
eBPF 64 bit register to 32 bit register mapping, although I don't have
any knowledge about the Hardware aspect of it.
Now, getting back to your slides, on Page 7 you are mapping eBPF 64
bit register to 32 bit register.
1. Can you explain that to me? I didn't get this part from you presentation.
2. How are you taking care of Race Condition on 64 bit eBPF registers
Read/Write as you are using 32 bit registers to emulate them ?
>
> What is your reason for looking at these problems?
I just wanted to contribute toward linux kernel. This is the only
reason I think.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
>
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
What about this ? Does this makes sense to you ?
>
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
What about this ?
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
>
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
>
Nick, It would be great if you could give me your comments/suggestions
on all of the above points for JIT implementation.
> Do you have any code references for me to take a look? Otherwise, I think
> its not possible for me to implement it without using any reference.
>
>
> I don't know anything else, no.
+Kees,
I think drivers/net/ethernet/netronome/nfp/ could be a good reference for this.
>
>
> I think, I will give it a try. Otherwise, my last 1 month which I used
> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
> waste.
>
>
>
> 2.) Also, is my current mapping good enough to make the JIT fast enough
> ?
> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> its instructions with native instructions.
>
>
> I don't know -- it might be tricky with needing to deal with 64-bit
> registers. But if you can make it faster than the non-JIT, it should
> be a win. :) Yay assembly.
>
>
> Well, As I mentioned above about my thinking towards the implementation,
> I am not sure it would be faster than non-JIT or even correct for that
> matter.
> It might be but I don't think I have enough knowledge to benchmark the
> implementation as of now.
Nick, How fast was your JIT as compared to interpreter if you had the
chance to benchmark them?
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-03 7:04 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-03 7:04 UTC (permalink / raw)
To: nick viljoen, Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
Hi Nick,
On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
<nick.viljoen@netronome.com> 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 check it out here :)
>
> https://www.youtube.com/watch?v=-5BzT1ch19s&t=45s
Sorry for the late reply. I had to watch the whole video. Its was fun.
Now. Its seems like a small of your complete project was related to
eBPF 64 bit register to 32 bit register mapping, although I don't have
any knowledge about the Hardware aspect of it.
Now, getting back to your slides, on Page 7 you are mapping eBPF 64
bit register to 32 bit register.
1. Can you explain that to me? I didn't get this part from you presentation.
2. How are you taking care of Race Condition on 64 bit eBPF registers
Read/Write as you are using 32 bit registers to emulate them ?
>
> What is your reason for looking at these problems?
I just wanted to contribute toward linux kernel. This is the only
reason I think.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
>
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
What about this ? Does this makes sense to you ?
>
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
What about this ?
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
>
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
>
Nick, It would be great if you could give me your comments/suggestions
on all of the above points for JIT implementation.
> Do you have any code references for me to take a look? Otherwise, I think
> its not possible for me to implement it without using any reference.
>
>
> I don't know anything else, no.
+Kees,
I think drivers/net/ethernet/netronome/nfp/ could be a good reference for this.
>
>
> I think, I will give it a try. Otherwise, my last 1 month which I used
> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
> waste.
>
>
>
> 2.) Also, is my current mapping good enough to make the JIT fast enough
> ?
> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> its instructions with native instructions.
>
>
> I don't know -- it might be tricky with needing to deal with 64-bit
> registers. But if you can make it faster than the non-JIT, it should
> be a win. :) Yay assembly.
>
>
> Well, As I mentioned above about my thinking towards the implementation,
> I am not sure it would be faster than non-JIT or even correct for that
> matter.
> It might be but I don't think I have enough knowledge to benchmark the
> implementation as of now.
Nick, How fast was your JIT as compared to interpreter if you had the
chance to benchmark them?
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-03 7:04 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-03 7:04 UTC (permalink / raw)
To: linux-arm-kernel
Hi Nick,
On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
<nick.viljoen@netronome.com> 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 check it out here :)
>
> https://www.youtube.com/watch?v=-5BzT1ch19s&t=45s
Sorry for the late reply. I had to watch the whole video. Its was fun.
Now. Its seems like a small of your complete project was related to
eBPF 64 bit register to 32 bit register mapping, although I don't have
any knowledge about the Hardware aspect of it.
Now, getting back to your slides, on Page 7 you are mapping eBPF 64
bit register to 32 bit register.
1. Can you explain that to me? I didn't get this part from you presentation.
2. How are you taking care of Race Condition on 64 bit eBPF registers
Read/Write as you are using 32 bit registers to emulate them ?
>
> What is your reason for looking at these problems?
I just wanted to contribute toward linux kernel. This is the only
reason I think.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
>
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
What about this ? Does this makes sense to you ?
>
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
What about this ?
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
>
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
>
Nick, It would be great if you could give me your comments/suggestions
on all of the above points for JIT implementation.
> Do you have any code references for me to take a look? Otherwise, I think
> its not possible for me to implement it without using any reference.
>
>
> I don't know anything else, no.
+Kees,
I think drivers/net/ethernet/netronome/nfp/ could be a good reference for this.
>
>
> I think, I will give it a try. Otherwise, my last 1 month which I used
> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
> waste.
>
>
>
> 2.) Also, is my current mapping good enough to make the JIT fast enough
> ?
> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
> its instructions with native instructions.
>
>
> I don't know -- it might be tricky with needing to deal with 64-bit
> registers. But if you can make it faster than the non-JIT, it should
> be a win. :) Yay assembly.
>
>
> Well, As I mentioned above about my thinking towards the implementation,
> I am not sure it would be faster than non-JIT or even correct for that
> matter.
> It might be but I don't think I have enough knowledge to benchmark the
> implementation as of now.
Nick, How fast was your JIT as compared to interpreter if you had the
chance to benchmark them?
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-02-03 7:04 ` Shubham Bansal
(?)
@ 2017-02-03 8:25 ` nick viljoen
-1 siblings, 0 replies; 67+ messages in thread
From: nick viljoen @ 2017-02-03 8:25 UTC (permalink / raw)
To: Shubham Bansal
Cc: Kees Cook, Daniel Borkmann, Mircea Gherzan, netdev,
kernel-hardening, linux-arm-kernel
> On Feb 2, 2017, at 11:04 PM, Shubham Bansal <illusionist.neo@gmail.com> wrote:
>
> Hi Nick,
>
> On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
> <nick.viljoen@netronome.com> 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 check it out here :)
>>
>> https://www.youtube.com/watch?v=-5BzT1ch19s&t=45s
>
> Sorry for the late reply. I had to watch the whole video. Its was fun.
> Now. Its seems like a small of your complete project was related to
> eBPF 64 bit register to 32 bit register mapping, although I don't have
> any knowledge about the Hardware aspect of it.
> Now, getting back to your slides, on Page 7 you are mapping eBPF 64
> bit register to 32 bit register.
>
> 1. Can you explain that to me? I didn't get this part from you presentation.
> 2. How are you taking care of Race Condition on 64 bit eBPF registers
> Read/Write as you are using 32 bit registers to emulate them ?
>
>>
>> What is your reason for looking at these problems?
>
> I just wanted to contribute toward linux kernel. This is the only
> reason I think.
There seems to have been some tying of emails here-my previous
email ended here-currently on my mail client it appears as though the
below is my email. As you have implied, I presume the below is you
replying to yourself.
-----------------------------------------
>
>> I was thinking of first implementing only instructions with 32 bit
>> register operands. It will hugely decrease the surface area of eBPF
>> instructions that I have to cover for the first patch.
>>
>> So, What I am thinking is something like this :
>>
>> - bpf_mov r0(64),r1(64) will be JITed like this :
>> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
>> bit and store it in arm register(ar1).
>> - Do MOV ar0(32),ar1(32) as an ARM instruction.
>> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
>> and store it in 64 bit ebpf register r0.
>
> What about this ? Does this makes sense to you ?
>>
>> - Similarly, For all BPF_ALU class instructions.
>> - For BPF_ADD, I will mask the addition result to 32 bit only.
>> I am not sure, Overflow might be a problem.
>> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
>> I am not sure, Underflow might be problem.
>> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
>> - For BPF_DIV, 32 bit masking should be fine, I guess.
>> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
>> masking should be fine.
>> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
>> - For BPF_END, 32 bit masking should work fine.
>> Let me know if any of the above point is wrong or need your suggestion.
> What about this ?
>>
>> - Although, for ALU instructions, there is a big problem of register
>> flag manipulations. Generally, architecture's ABI takes care of this
>> part but as we are doing 64 bit Instructions emulation(kind of) on 32
>> bit machine, it needs to be done manually. Does that sound correct ?
>>
>> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
>> take care of atomic instructions and race conditions with these
>> instruction which looks complicated to me as of now. Will try to figure out
>> this part and implement it later. Currently, I will just let it be
>> interpreted by the ebpf interpreter.
>>
>> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
>> the address pointers on 32 bit arch like arm will be of 32 bit only.
>> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
>> should do the trick and no address will be corrupted in this way. Am I
>> correct to assume this ?
>> Also, I need to check for address getting out of the allowed memory
>> range.
>>
>> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
>> assuming the same thing as above - All addresses and pointers are 32
>> bit - which can be taken care just by maksing the eBPF register
>> values. Does that sound correct ?
>> Also, I need to check for the address overflow, address getting out
>> of the allowed memory range and things like that.
>>
> Nick, It would be great if you could give me your comments/suggestions
> on all of the above points for JIT implementation.
As we are selectively offloading to a NPU based NIC we can avoid some of
the problems you have mentioned so I am afraid I don't have all the
answers
While we have stated publicly we are doing this work and aren't trying to
hide anything, the reason I replied to you in private is that it is generally
not a good idea to share half baked ideas on the mailing list as it wastes
peoples time :).
The best approach is to wait until you are able to post an RFC patch for
public discussion.
>
>> Do you have any code references for me to take a look? Otherwise, I think
>> its not possible for me to implement it without using any reference.
>>
>>
>> I don't know anything else, no.
>
> +Kees,
>
> I think drivers/net/ethernet/netronome/nfp/ could be a good reference for this.
>
>>
>>
>> I think, I will give it a try. Otherwise, my last 1 month which I used
>> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
>> waste.
>>
>>
>>
>> 2.) Also, is my current mapping good enough to make the JIT fast enough
>> ?
>> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
>> its instructions with native instructions.
>>
>>
>> I don't know -- it might be tricky with needing to deal with 64-bit
>> registers. But if you can make it faster than the non-JIT, it should
>> be a win. :) Yay assembly.
>>
>>
>> Well, As I mentioned above about my thinking towards the implementation,
>> I am not sure it would be faster than non-JIT or even correct for that
>> matter.
>> It might be but I don't think I have enough knowledge to benchmark the
>> implementation as of now.
>
> Nick, How fast was your JIT as compared to interpreter if you had the
> chance to benchmark them?
>
> -Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-03 8:25 ` nick viljoen
0 siblings, 0 replies; 67+ messages in thread
From: nick viljoen @ 2017-02-03 8:25 UTC (permalink / raw)
To: Shubham Bansal
Cc: Kees Cook, Daniel Borkmann, Mircea Gherzan, netdev,
kernel-hardening, linux-arm-kernel
> On Feb 2, 2017, at 11:04 PM, Shubham Bansal <illusionist.neo@gmail.com> wrote:
>
> Hi Nick,
>
> On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
> <nick.viljoen@netronome.com> 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 check it out here :)
>>
>> https://www.youtube.com/watch?v=-5BzT1ch19s&t=45s
>
> Sorry for the late reply. I had to watch the whole video. Its was fun.
> Now. Its seems like a small of your complete project was related to
> eBPF 64 bit register to 32 bit register mapping, although I don't have
> any knowledge about the Hardware aspect of it.
> Now, getting back to your slides, on Page 7 you are mapping eBPF 64
> bit register to 32 bit register.
>
> 1. Can you explain that to me? I didn't get this part from you presentation.
> 2. How are you taking care of Race Condition on 64 bit eBPF registers
> Read/Write as you are using 32 bit registers to emulate them ?
>
>>
>> What is your reason for looking at these problems?
>
> I just wanted to contribute toward linux kernel. This is the only
> reason I think.
There seems to have been some tying of emails here-my previous
email ended here-currently on my mail client it appears as though the
below is my email. As you have implied, I presume the below is you
replying to yourself.
-----------------------------------------
>
>> I was thinking of first implementing only instructions with 32 bit
>> register operands. It will hugely decrease the surface area of eBPF
>> instructions that I have to cover for the first patch.
>>
>> So, What I am thinking is something like this :
>>
>> - bpf_mov r0(64),r1(64) will be JITed like this :
>> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
>> bit and store it in arm register(ar1).
>> - Do MOV ar0(32),ar1(32) as an ARM instruction.
>> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
>> and store it in 64 bit ebpf register r0.
>
> What about this ? Does this makes sense to you ?
>>
>> - Similarly, For all BPF_ALU class instructions.
>> - For BPF_ADD, I will mask the addition result to 32 bit only.
>> I am not sure, Overflow might be a problem.
>> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
>> I am not sure, Underflow might be problem.
>> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
>> - For BPF_DIV, 32 bit masking should be fine, I guess.
>> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
>> masking should be fine.
>> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
>> - For BPF_END, 32 bit masking should work fine.
>> Let me know if any of the above point is wrong or need your suggestion.
> What about this ?
>>
>> - Although, for ALU instructions, there is a big problem of register
>> flag manipulations. Generally, architecture's ABI takes care of this
>> part but as we are doing 64 bit Instructions emulation(kind of) on 32
>> bit machine, it needs to be done manually. Does that sound correct ?
>>
>> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
>> take care of atomic instructions and race conditions with these
>> instruction which looks complicated to me as of now. Will try to figure out
>> this part and implement it later. Currently, I will just let it be
>> interpreted by the ebpf interpreter.
>>
>> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
>> the address pointers on 32 bit arch like arm will be of 32 bit only.
>> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
>> should do the trick and no address will be corrupted in this way. Am I
>> correct to assume this ?
>> Also, I need to check for address getting out of the allowed memory
>> range.
>>
>> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
>> assuming the same thing as above - All addresses and pointers are 32
>> bit - which can be taken care just by maksing the eBPF register
>> values. Does that sound correct ?
>> Also, I need to check for the address overflow, address getting out
>> of the allowed memory range and things like that.
>>
> Nick, It would be great if you could give me your comments/suggestions
> on all of the above points for JIT implementation.
As we are selectively offloading to a NPU based NIC we can avoid some of
the problems you have mentioned so I am afraid I don't have all the
answers
While we have stated publicly we are doing this work and aren't trying to
hide anything, the reason I replied to you in private is that it is generally
not a good idea to share half baked ideas on the mailing list as it wastes
peoples time :).
The best approach is to wait until you are able to post an RFC patch for
public discussion.
>
>> Do you have any code references for me to take a look? Otherwise, I think
>> its not possible for me to implement it without using any reference.
>>
>>
>> I don't know anything else, no.
>
> +Kees,
>
> I think drivers/net/ethernet/netronome/nfp/ could be a good reference for this.
>
>>
>>
>> I think, I will give it a try. Otherwise, my last 1 month which I used
>> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
>> waste.
>>
>>
>>
>> 2.) Also, is my current mapping good enough to make the JIT fast enough
>> ?
>> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
>> its instructions with native instructions.
>>
>>
>> I don't know -- it might be tricky with needing to deal with 64-bit
>> registers. But if you can make it faster than the non-JIT, it should
>> be a win. :) Yay assembly.
>>
>>
>> Well, As I mentioned above about my thinking towards the implementation,
>> I am not sure it would be faster than non-JIT or even correct for that
>> matter.
>> It might be but I don't think I have enough knowledge to benchmark the
>> implementation as of now.
>
> Nick, How fast was your JIT as compared to interpreter if you had the
> chance to benchmark them?
>
> -Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-03 8:25 ` nick viljoen
0 siblings, 0 replies; 67+ messages in thread
From: nick viljoen @ 2017-02-03 8:25 UTC (permalink / raw)
To: linux-arm-kernel
> On Feb 2, 2017, at 11:04 PM, Shubham Bansal <illusionist.neo@gmail.com> wrote:
>
> Hi Nick,
>
> On Thu, Feb 2, 2017 at 12:59 PM, nick viljoen
> <nick.viljoen@netronome.com> 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 check it out here :)
>>
>> https://www.youtube.com/watch?v=-5BzT1ch19s&t=45s
>
> Sorry for the late reply. I had to watch the whole video. Its was fun.
> Now. Its seems like a small of your complete project was related to
> eBPF 64 bit register to 32 bit register mapping, although I don't have
> any knowledge about the Hardware aspect of it.
> Now, getting back to your slides, on Page 7 you are mapping eBPF 64
> bit register to 32 bit register.
>
> 1. Can you explain that to me? I didn't get this part from you presentation.
> 2. How are you taking care of Race Condition on 64 bit eBPF registers
> Read/Write as you are using 32 bit registers to emulate them ?
>
>>
>> What is your reason for looking at these problems?
>
> I just wanted to contribute toward linux kernel. This is the only
> reason I think.
There seems to have been some tying of emails here-my previous
email ended here-currently on my mail client it appears as though the
below is my email. As you have implied, I presume the below is you
replying to yourself.
-----------------------------------------
>
>> I was thinking of first implementing only instructions with 32 bit
>> register operands. It will hugely decrease the surface area of eBPF
>> instructions that I have to cover for the first patch.
>>
>> So, What I am thinking is something like this :
>>
>> - bpf_mov r0(64),r1(64) will be JITed like this :
>> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
>> bit and store it in arm register(ar1).
>> - Do MOV ar0(32),ar1(32) as an ARM instruction.
>> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
>> and store it in 64 bit ebpf register r0.
>
> What about this ? Does this makes sense to you ?
>>
>> - Similarly, For all BPF_ALU class instructions.
>> - For BPF_ADD, I will mask the addition result to 32 bit only.
>> I am not sure, Overflow might be a problem.
>> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
>> I am not sure, Underflow might be problem.
>> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
>> - For BPF_DIV, 32 bit masking should be fine, I guess.
>> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
>> masking should be fine.
>> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
>> - For BPF_END, 32 bit masking should work fine.
>> Let me know if any of the above point is wrong or need your suggestion.
> What about this ?
>>
>> - Although, for ALU instructions, there is a big problem of register
>> flag manipulations. Generally, architecture's ABI takes care of this
>> part but as we are doing 64 bit Instructions emulation(kind of) on 32
>> bit machine, it needs to be done manually. Does that sound correct ?
>>
>> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
>> take care of atomic instructions and race conditions with these
>> instruction which looks complicated to me as of now. Will try to figure out
>> this part and implement it later. Currently, I will just let it be
>> interpreted by the ebpf interpreter.
>>
>> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
>> the address pointers on 32 bit arch like arm will be of 32 bit only.
>> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
>> should do the trick and no address will be corrupted in this way. Am I
>> correct to assume this ?
>> Also, I need to check for address getting out of the allowed memory
>> range.
>>
>> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
>> assuming the same thing as above - All addresses and pointers are 32
>> bit - which can be taken care just by maksing the eBPF register
>> values. Does that sound correct ?
>> Also, I need to check for the address overflow, address getting out
>> of the allowed memory range and things like that.
>>
> Nick, It would be great if you could give me your comments/suggestions
> on all of the above points for JIT implementation.
As we are selectively offloading to a NPU based NIC we can avoid some of
the problems you have mentioned so I am afraid I don't have all the
answers
While we have stated publicly we are doing this work and aren't trying to
hide anything, the reason I replied to you in private is that it is generally
not a good idea to share half baked ideas on the mailing list as it wastes
peoples time :).
The best approach is to wait until you are able to post an RFC patch for
public discussion.
>
>> Do you have any code references for me to take a look? Otherwise, I think
>> its not possible for me to implement it without using any reference.
>>
>>
>> I don't know anything else, no.
>
> +Kees,
>
> I think drivers/net/ethernet/netronome/nfp/ could be a good reference for this.
>
>>
>>
>> I think, I will give it a try. Otherwise, my last 1 month which I used
>> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
>> waste.
>>
>>
>>
>> 2.) Also, is my current mapping good enough to make the JIT fast enough
>> ?
>> because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
>> its instructions with native instructions.
>>
>>
>> I don't know -- it might be tricky with needing to deal with 64-bit
>> registers. But if you can make it faster than the non-JIT, it should
>> be a win. :) Yay assembly.
>>
>>
>> Well, As I mentioned above about my thinking towards the implementation,
>> I am not sure it would be faster than non-JIT or even correct for that
>> matter.
>> It might be but I don't think I have enough knowledge to benchmark the
>> implementation as of now.
>
> Nick, How fast was your JIT as compared to interpreter if you had the
> chance to benchmark them?
>
> -Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-02-01 13:01 ` Shubham Bansal
(?)
@ 2017-02-08 7:29 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-08 7:29 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
Anybody willing to take swing at my following comments ?
On Wed, Feb 1, 2017 at 6:31 PM, Shubham Bansal
<illusionist.neo@gmail.com> 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
>> >> > have some idea about how to map eBPF->arm 32 bit registers ?
>> >>
>> >> I was going to say "look at the x86 32-bit implementation." ... But
>> >> there isn't one. :( I'm going to guess that there isn't a very good
>> >> answer here. I assume you'll have to build some kind of stack scratch
>> >> space to load/save.
>> >
>> >
>> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
>> > think its very difficult to implement it without any complications and
>> > errors.
>>
>> Yeah, that does seem to make it much more difficult.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
>
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
>
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
>
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
>
>> > Do you have any code references for me to take a look? Otherwise, I think
>> > its not possible for me to implement it without using any reference.
>>
>> I don't know anything else, no.
>
> I think, I will give it a try. Otherwise, my last 1 month which I used
> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
> waste.
>
>> >>
>> >>
>> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
>> >> > ?
>> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
>> >> > its instructions with native instructions.
>> >>
>> >> I don't know -- it might be tricky with needing to deal with 64-bit
>> >> registers. But if you can make it faster than the non-JIT, it should
>> >> be a win. :) Yay assembly.
>
> Well, As I mentioned above about my thinking towards the implementation,
> I am not sure it would be faster than non-JIT or even correct for that matter.
> It might be but I don't think I have enough knowledge to benchmark the
> implementation as of now.
>
>
> -Shubham Bansal
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-08 7:29 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-08 7:29 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, netdev, kernel-hardening,
linux-arm-kernel
Anybody willing to take swing at my following comments ?
On Wed, Feb 1, 2017 at 6:31 PM, Shubham Bansal
<illusionist.neo@gmail.com> 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
>> >> > have some idea about how to map eBPF->arm 32 bit registers ?
>> >>
>> >> I was going to say "look at the x86 32-bit implementation." ... But
>> >> there isn't one. :( I'm going to guess that there isn't a very good
>> >> answer here. I assume you'll have to build some kind of stack scratch
>> >> space to load/save.
>> >
>> >
>> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
>> > think its very difficult to implement it without any complications and
>> > errors.
>>
>> Yeah, that does seem to make it much more difficult.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
>
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
>
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
>
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
>
>> > Do you have any code references for me to take a look? Otherwise, I think
>> > its not possible for me to implement it without using any reference.
>>
>> I don't know anything else, no.
>
> I think, I will give it a try. Otherwise, my last 1 month which I used
> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
> waste.
>
>> >>
>> >>
>> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
>> >> > ?
>> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
>> >> > its instructions with native instructions.
>> >>
>> >> I don't know -- it might be tricky with needing to deal with 64-bit
>> >> registers. But if you can make it faster than the non-JIT, it should
>> >> be a win. :) Yay assembly.
>
> Well, As I mentioned above about my thinking towards the implementation,
> I am not sure it would be faster than non-JIT or even correct for that matter.
> It might be but I don't think I have enough knowledge to benchmark the
> implementation as of now.
>
>
> -Shubham Bansal
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-08 7:29 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-02-08 7:29 UTC (permalink / raw)
To: linux-arm-kernel
Anybody willing to take swing at my following comments ?
On Wed, Feb 1, 2017 at 6:31 PM, Shubham Bansal
<illusionist.neo@gmail.com> 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
>> >> > have some idea about how to map eBPF->arm 32 bit registers ?
>> >>
>> >> I was going to say "look at the x86 32-bit implementation." ... But
>> >> there isn't one. :( I'm going to guess that there isn't a very good
>> >> answer here. I assume you'll have to build some kind of stack scratch
>> >> space to load/save.
>> >
>> >
>> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
>> > think its very difficult to implement it without any complications and
>> > errors.
>>
>> Yeah, that does seem to make it much more difficult.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
>
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
>
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
>
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
>
>> > Do you have any code references for me to take a look? Otherwise, I think
>> > its not possible for me to implement it without using any reference.
>>
>> I don't know anything else, no.
>
> I think, I will give it a try. Otherwise, my last 1 month which I used
> to read about eBPF, eBPF linux code and arm32 ABI would be a complete
> waste.
>
>> >>
>> >>
>> >> > 2.) Also, is my current mapping good enough to make the JIT fast enough
>> >> > ?
>> >> > because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
>> >> > its instructions with native instructions.
>> >>
>> >> I don't know -- it might be tricky with needing to deal with 64-bit
>> >> registers. But if you can make it faster than the non-JIT, it should
>> >> be a win. :) Yay assembly.
>
> Well, As I mentioned above about my thinking towards the implementation,
> I am not sure it would be faster than non-JIT or even correct for that matter.
> It might be but I don't think I have enough knowledge to benchmark the
> implementation as of now.
>
>
> -Shubham Bansal
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-02-01 13:01 ` Shubham Bansal
(?)
@ 2017-02-08 19:41 ` Kees Cook
-1 siblings, 0 replies; 67+ messages in thread
From: Kees Cook @ 2017-02-08 19:41 UTC (permalink / raw)
To: Shubham Bansal
Cc: Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel
On Wed, Feb 1, 2017 at 5:01 AM, Shubham Bansal
<illusionist.neo@gmail.com> 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
>> >> > have some idea about how to map eBPF->arm 32 bit registers ?
>> >>
>> >> I was going to say "look at the x86 32-bit implementation." ... But
>> >> there isn't one. :( I'm going to guess that there isn't a very good
>> >> answer here. I assume you'll have to build some kind of stack scratch
>> >> space to load/save.
>> >
>> >
>> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
>> > think its very difficult to implement it without any complications and
>> > errors.
>>
>> Yeah, that does seem to make it much more difficult.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
I don't know much about eBPF internals, but I can take a crack at
answering this... I assume whatever you implement would need to pass
the BPF regression tests...
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
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.
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
You can't truncate, but you'll have to build 64-bit ops using 32-bit registers.
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
That's probably true, but the JIT should likely detect a truncation
here, if you're going to depend on it, and reject the BPF.
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
I'd say, get something working and send a patch -- that's likely the
best way to get more detailed feedback. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-08 19:41 ` Kees Cook
0 siblings, 0 replies; 67+ messages in thread
From: Kees Cook @ 2017-02-08 19:41 UTC (permalink / raw)
To: Shubham Bansal
Cc: Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel
On Wed, Feb 1, 2017 at 5:01 AM, Shubham Bansal
<illusionist.neo@gmail.com> 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
>> >> > have some idea about how to map eBPF->arm 32 bit registers ?
>> >>
>> >> I was going to say "look at the x86 32-bit implementation." ... But
>> >> there isn't one. :( I'm going to guess that there isn't a very good
>> >> answer here. I assume you'll have to build some kind of stack scratch
>> >> space to load/save.
>> >
>> >
>> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
>> > think its very difficult to implement it without any complications and
>> > errors.
>>
>> Yeah, that does seem to make it much more difficult.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
I don't know much about eBPF internals, but I can take a crack at
answering this... I assume whatever you implement would need to pass
the BPF regression tests...
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
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.
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
You can't truncate, but you'll have to build 64-bit ops using 32-bit registers.
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
That's probably true, but the JIT should likely detect a truncation
here, if you're going to depend on it, and reject the BPF.
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
I'd say, get something working and send a patch -- that's likely the
best way to get more detailed feedback. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-02-08 19:41 ` Kees Cook
0 siblings, 0 replies; 67+ messages in thread
From: Kees Cook @ 2017-02-08 19:41 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Feb 1, 2017 at 5:01 AM, Shubham Bansal
<illusionist.neo@gmail.com> 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
>> >> > have some idea about how to map eBPF->arm 32 bit registers ?
>> >>
>> >> I was going to say "look at the x86 32-bit implementation." ... But
>> >> there isn't one. :( I'm going to guess that there isn't a very good
>> >> answer here. I assume you'll have to build some kind of stack scratch
>> >> space to load/save.
>> >
>> >
>> > Now I see why nobody has implemented eBPF JIT for the 32 bit systems. I
>> > think its very difficult to implement it without any complications and
>> > errors.
>>
>> Yeah, that does seem to make it much more difficult.
> I was thinking of first implementing only instructions with 32 bit
> register operands. It will hugely decrease the surface area of eBPF
> instructions that I have to cover for the first patch.
I don't know much about eBPF internals, but I can take a crack at
answering this... I assume whatever you implement would need to pass
the BPF regression tests...
> So, What I am thinking is something like this :
>
> - bpf_mov r0(64),r1(64) will be JITed like this :
> - ar1(32) <- r1(64). Convert/Mask 64 bit ebpf register(r1) value into 32
> bit and store it in arm register(ar1).
> - Do MOV ar0(32),ar1(32) as an ARM instruction.
> - ar0(32) -> r0(64). Zero Extend the ar0 32 bit register value
> and store it in 64 bit ebpf register r0.
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.
> - Similarly, For all BPF_ALU class instructions.
> - For BPF_ADD, I will mask the addition result to 32 bit only.
> I am not sure, Overflow might be a problem.
> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
> I am not sure, Underflow might be problem.
> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
> - For BPF_DIV, 32 bit masking should be fine, I guess.
> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
> masking should be fine.
> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
> - For BPF_END, 32 bit masking should work fine.
> Let me know if any of the above point is wrong or need your suggestion.
>
> - Although, for ALU instructions, there is a big problem of register
> flag manipulations. Generally, architecture's ABI takes care of this
> part but as we are doing 64 bit Instructions emulation(kind of) on 32
> bit machine, it needs to be done manually. Does that sound correct ?
You can't truncate, but you'll have to build 64-bit ops using 32-bit registers.
>
> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
> take care of atomic instructions and race conditions with these
> instruction which looks complicated to me as of now. Will try to figure out
> this part and implement it later. Currently, I will just let it be
> interpreted by the ebpf interpreter.
>
> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
> the address pointers on 32 bit arch like arm will be of 32 bit only.
> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
> should do the trick and no address will be corrupted in this way. Am I
> correct to assume this ?
> Also, I need to check for address getting out of the allowed memory
> range.
That's probably true, but the JIT should likely detect a truncation
here, if you're going to depend on it, and reject the BPF.
> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
> assuming the same thing as above - All addresses and pointers are 32
> bit - which can be taken care just by maksing the eBPF register
> values. Does that sound correct ?
> Also, I need to check for the address overflow, address getting out
> of the allowed memory range and things like that.
I'd say, get something working and send a patch -- that's likely the
best way to get more detailed feedback. :)
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-02-08 19:41 ` Kees Cook
(?)
@ 2017-03-15 12:13 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-15 12:13 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel
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, but
for 32 bit operands only. So when I am truncating the BPF register, I
am getting rid of non-useful bytes only.
Can you explain how to use memory scratch space and build 64-bit
operations using 32-bit registers and memory operations ? A small
example would help a lot.
>> - Similarly, For all BPF_ALU class instructions.
>> - For BPF_ADD, I will mask the addition result to 32 bit only.
>> I am not sure, Overflow might be a problem.
>> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
>> I am not sure, Underflow might be problem.
>> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
>> - For BPF_DIV, 32 bit masking should be fine, I guess.
>> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
>> masking should be fine.
>> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
>> - For BPF_END, 32 bit masking should work fine.
>> Let me know if any of the above point is wrong or need your suggestion.
>>
>> - Although, for ALU instructions, there is a big problem of register
>> flag manipulations. Generally, architecture's ABI takes care of this
>> part but as we are doing 64 bit Instructions emulation(kind of) on 32
>> bit machine, it needs to be done manually. Does that sound correct ?
>
> You can't truncate, but you'll have to build 64-bit ops using 32-bit registers.
A small example would help a lot.
>
>>
>> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
>> take care of atomic instructions and race conditions with these
>> instruction which looks complicated to me as of now. Will try to figure out
>> this part and implement it later. Currently, I will just let it be
>> interpreted by the ebpf interpreter.
>>
>> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
>> the address pointers on 32 bit arch like arm will be of 32 bit only.
>> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
>> should do the trick and no address will be corrupted in this way. Am I
>> correct to assume this ?
>> Also, I need to check for address getting out of the allowed memory
>> range.
>
> That's probably true, but the JIT should likely detect a truncation
> here, if you're going to depend on it, and reject the BPF.
Okay. So I guess I have to use memory for this as well ?
An example would be great.
>
>> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
>> assuming the same thing as above - All addresses and pointers are 32
>> bit - which can be taken care just by maksing the eBPF register
>> values. Does that sound correct ?
>> Also, I need to check for the address overflow, address getting out
>> of the allowed memory range and things like that.
>
> I'd say, get something working and send a patch -- that's likely the
> best way to get more detailed feedback. :)
I would love to but I have to understand what to implement first.
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-15 12:13 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-15 12:13 UTC (permalink / raw)
To: Kees Cook
Cc: Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel
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, but
for 32 bit operands only. So when I am truncating the BPF register, I
am getting rid of non-useful bytes only.
Can you explain how to use memory scratch space and build 64-bit
operations using 32-bit registers and memory operations ? A small
example would help a lot.
>> - Similarly, For all BPF_ALU class instructions.
>> - For BPF_ADD, I will mask the addition result to 32 bit only.
>> I am not sure, Overflow might be a problem.
>> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
>> I am not sure, Underflow might be problem.
>> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
>> - For BPF_DIV, 32 bit masking should be fine, I guess.
>> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
>> masking should be fine.
>> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
>> - For BPF_END, 32 bit masking should work fine.
>> Let me know if any of the above point is wrong or need your suggestion.
>>
>> - Although, for ALU instructions, there is a big problem of register
>> flag manipulations. Generally, architecture's ABI takes care of this
>> part but as we are doing 64 bit Instructions emulation(kind of) on 32
>> bit machine, it needs to be done manually. Does that sound correct ?
>
> You can't truncate, but you'll have to build 64-bit ops using 32-bit registers.
A small example would help a lot.
>
>>
>> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
>> take care of atomic instructions and race conditions with these
>> instruction which looks complicated to me as of now. Will try to figure out
>> this part and implement it later. Currently, I will just let it be
>> interpreted by the ebpf interpreter.
>>
>> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
>> the address pointers on 32 bit arch like arm will be of 32 bit only.
>> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
>> should do the trick and no address will be corrupted in this way. Am I
>> correct to assume this ?
>> Also, I need to check for address getting out of the allowed memory
>> range.
>
> That's probably true, but the JIT should likely detect a truncation
> here, if you're going to depend on it, and reject the BPF.
Okay. So I guess I have to use memory for this as well ?
An example would be great.
>
>> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
>> assuming the same thing as above - All addresses and pointers are 32
>> bit - which can be taken care just by maksing the eBPF register
>> values. Does that sound correct ?
>> Also, I need to check for the address overflow, address getting out
>> of the allowed memory range and things like that.
>
> I'd say, get something working and send a patch -- that's likely the
> best way to get more detailed feedback. :)
I would love to but I have to understand what to implement first.
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-15 12:13 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-15 12:13 UTC (permalink / raw)
To: linux-arm-kernel
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, but
for 32 bit operands only. So when I am truncating the BPF register, I
am getting rid of non-useful bytes only.
Can you explain how to use memory scratch space and build 64-bit
operations using 32-bit registers and memory operations ? A small
example would help a lot.
>> - Similarly, For all BPF_ALU class instructions.
>> - For BPF_ADD, I will mask the addition result to 32 bit only.
>> I am not sure, Overflow might be a problem.
>> - For BPF_SUB, I will mask the subtraction result to 32 bit only.
>> I am not sure, Underflow might be problem.
>> - For BPF_MUL, similar to BPF_ADD. Overflow Problem ?
>> - For BPF_DIV, 32 bit masking should be fine, I guess.
>> - For BPF_OR, BPF_AND, BPF_XOR, BPF_LSH, BPF_RSH, BPF_MOD 32 bit
>> masking should be fine.
>> - For BPF_NEG and BPF_ARSH, might be a problem because of the sign bit.
>> - For BPF_END, 32 bit masking should work fine.
>> Let me know if any of the above point is wrong or need your suggestion.
>>
>> - Although, for ALU instructions, there is a big problem of register
>> flag manipulations. Generally, architecture's ABI takes care of this
>> part but as we are doing 64 bit Instructions emulation(kind of) on 32
>> bit machine, it needs to be done manually. Does that sound correct ?
>
> You can't truncate, but you'll have to build 64-bit ops using 32-bit registers.
A small example would help a lot.
>
>>
>> - I am not JITing BPF_ALU64 class instructions as of now. As we have to
>> take care of atomic instructions and race conditions with these
>> instruction which looks complicated to me as of now. Will try to figure out
>> this part and implement it later. Currently, I will just let it be
>> interpreted by the ebpf interpreter.
>>
>> - For BPF_JMP class, I am assuming that, although eBPF is 64 bit ABI,
>> the address pointers on 32 bit arch like arm will be of 32 bit only.
>> So, for BPF_JMP, masking the 64 bit destination address to 32 bit
>> should do the trick and no address will be corrupted in this way. Am I
>> correct to assume this ?
>> Also, I need to check for address getting out of the allowed memory
>> range.
>
> That's probably true, but the JIT should likely detect a truncation
> here, if you're going to depend on it, and reject the BPF.
Okay. So I guess I have to use memory for this as well ?
An example would be great.
>
>> - For BPF_LD, BPF_LDX, BPF_ST and BPF_STX class instructions, I am
>> assuming the same thing as above - All addresses and pointers are 32
>> bit - which can be taken care just by maksing the eBPF register
>> values. Does that sound correct ?
>> Also, I need to check for the address overflow, address getting out
>> of the allowed memory range and things like that.
>
> I'd say, get something working and send a patch -- that's likely the
> best way to get more detailed feedback. :)
I would love to but I have to understand what to implement first.
-Shubham
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-03-15 12:13 ` Shubham Bansal
(?)
@ 2017-03-15 21:55 ` David Miller
-1 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-03-15 21:55 UTC (permalink / raw)
To: illusionist.neo
Cc: keescook, daniel, mgherzan, netdev, kernel-hardening, linux-arm-kernel
From: Shubham Bansal <illusionist.neo@gmail.com>
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-15 21:55 ` David Miller
0 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-03-15 21:55 UTC (permalink / raw)
To: illusionist.neo
Cc: keescook, daniel, mgherzan, netdev, kernel-hardening, linux-arm-kernel
From: Shubham Bansal <illusionist.neo@gmail.com>
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-15 21:55 ` David Miller
0 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-03-15 21:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Shubham Bansal <illusionist.neo@gmail.com>
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-03-15 21:55 ` David Miller
(?)
@ 2017-03-28 20:49 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-28 20:49 UTC (permalink / raw)
To: David Miller
Cc: Kees Cook, Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel
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 presentations. I just need a very
general idea. May be you know the code in kernel where it is
implemented.
Thanks for the help Daniel.
Best,
Shubham Bansal
On Thu, Mar 16, 2017 at 3:25 AM, David Miller <davem@davemloft.net> wrote:
> From: Shubham Bansal <illusionist.neo@gmail.com>
> 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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-28 20:49 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-28 20:49 UTC (permalink / raw)
To: David Miller
Cc: Kees Cook, Daniel Borkmann, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel
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 presentations. I just need a very
general idea. May be you know the code in kernel where it is
implemented.
Thanks for the help Daniel.
Best,
Shubham Bansal
On Thu, Mar 16, 2017 at 3:25 AM, David Miller <davem@davemloft.net> wrote:
> From: Shubham Bansal <illusionist.neo@gmail.com>
> 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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-28 20:49 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-28 20:49 UTC (permalink / raw)
To: linux-arm-kernel
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 presentations. I just need a very
general idea. May be you know the code in kernel where it is
implemented.
Thanks for the help Daniel.
Best,
Shubham Bansal
On Thu, Mar 16, 2017 at 3:25 AM, David Miller <davem@davemloft.net> wrote:
> From: Shubham Bansal <illusionist.neo@gmail.com>
> 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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-03-28 20:49 ` Shubham Bansal
(?)
@ 2017-03-29 0:00 ` Daniel Borkmann
-1 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-03-29 0:00 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 from your presentations. I just need a very
> general idea. May be you know the code in kernel where it is
> implemented.
Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c +1019).
That's effectively what JITs implement. [1] page 3 has a high-level description
as well, hope that helps.
Thanks,
Daniel
[1] http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-29 0:00 ` Daniel Borkmann
0 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-03-29 0:00 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 from your presentations. I just need a very
> general idea. May be you know the code in kernel where it is
> implemented.
Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c +1019).
That's effectively what JITs implement. [1] page 3 has a high-level description
as well, hope that helps.
Thanks,
Daniel
[1] http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-29 0:00 ` Daniel Borkmann
0 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-03-29 0:00 UTC (permalink / raw)
To: linux-arm-kernel
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 from your presentations. I just need a very
> general idea. May be you know the code in kernel where it is
> implemented.
Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c +1019).
That's effectively what JITs implement. [1] page 3 has a high-level description
as well, hope that helps.
Thanks,
Daniel
[1] http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-03-29 0:00 ` Daniel Borkmann
(?)
@ 2017-03-30 14:04 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-30 14:04 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 <daniel@iogearbox.net> 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 from your presentations. I just need a very
>> general idea. May be you know the code in kernel where it is
>> implemented.
>
>
> Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c
> +1019).
> That's effectively what JITs implement. [1] page 3 has a high-level
> description
> as well, hope that helps.
>
> Thanks,
> Daniel
>
> [1]
> http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-30 14:04 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-30 14:04 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 <daniel@iogearbox.net> 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 from your presentations. I just need a very
>> general idea. May be you know the code in kernel where it is
>> implemented.
>
>
> Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c
> +1019).
> That's effectively what JITs implement. [1] page 3 has a high-level
> description
> as well, hope that helps.
>
> Thanks,
> Daniel
>
> [1]
> http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-03-30 14:04 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-03-30 14:04 UTC (permalink / raw)
To: linux-arm-kernel
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 <daniel@iogearbox.net> 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 from your presentations. I just need a very
>> general idea. May be you know the code in kernel where it is
>> implemented.
>
>
> Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c
> +1019).
> That's effectively what JITs implement. [1] page 3 has a high-level
> description
> as well, hope that helps.
>
> Thanks,
> Daniel
>
> [1]
> http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-03-30 14:04 ` Shubham Bansal
(?)
@ 2017-04-06 11:05 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-04-06 11:05 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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
<illusionist.neo@gmail.com> 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 testing.
> Best,
> Shubham Bansal
>
>
> On Wed, Mar 29, 2017 at 5:30 AM, Daniel Borkmann <daniel@iogearbox.net> 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 from your presentations. I just need a very
>>> general idea. May be you know the code in kernel where it is
>>> implemented.
>>
>>
>> Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c
>> +1019).
>> That's effectively what JITs implement. [1] page 3 has a high-level
>> description
>> as well, hope that helps.
>>
>> Thanks,
>> Daniel
>>
>> [1]
>> http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-04-06 11:05 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-04-06 11:05 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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
<illusionist.neo@gmail.com> 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 testing.
> Best,
> Shubham Bansal
>
>
> On Wed, Mar 29, 2017 at 5:30 AM, Daniel Borkmann <daniel@iogearbox.net> 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 from your presentations. I just need a very
>>> general idea. May be you know the code in kernel where it is
>>> implemented.
>>
>>
>> Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c
>> +1019).
>> That's effectively what JITs implement. [1] page 3 has a high-level
>> description
>> as well, hope that helps.
>>
>> Thanks,
>> Daniel
>>
>> [1]
>> http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-04-06 11:05 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-04-06 11:05 UTC (permalink / raw)
To: linux-arm-kernel
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
<illusionist.neo@gmail.com> 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 testing.
> Best,
> Shubham Bansal
>
>
> On Wed, Mar 29, 2017 at 5:30 AM, Daniel Borkmann <daniel@iogearbox.net> 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 from your presentations. I just need a very
>>> general idea. May be you know the code in kernel where it is
>>> implemented.
>>
>>
>> Sure, it's in __bpf_prog_run(), see the JMP_TAIL_CALL (kernel/bpf/core.c
>> +1019).
>> That's effectively what JITs implement. [1] page 3 has a high-level
>> description
>> as well, hope that helps.
>>
>> Thanks,
>> Daniel
>>
>> [1]
>> http://www.netdevconf.org/1.1/proceedings/papers/On-getting-tc-classifier-fully-programmable-with-cls-bpf.pdf
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-04-06 11:05 ` Shubham Bansal
(?)
@ 2017-04-06 12:51 ` Daniel Borkmann
-1 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-04-06 12:51 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 purpose to test the JIT with corner cases. If you see a useful
test missing, please send a patch for it, so all other JITs can benefit
from this as well. For extracting disassembly from a generated test case,
check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
Thanks,
Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-04-06 12:51 ` Daniel Borkmann
0 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-04-06 12:51 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 purpose to test the JIT with corner cases. If you see a useful
test missing, please send a patch for it, so all other JITs can benefit
from this as well. For extracting disassembly from a generated test case,
check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
Thanks,
Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-04-06 12:51 ` Daniel Borkmann
0 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-04-06 12:51 UTC (permalink / raw)
To: linux-arm-kernel
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 purpose to test the JIT with corner cases. If you see a useful
test missing, please send a patch for it, so all other JITs can benefit
from this as well. For extracting disassembly from a generated test case,
check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
Thanks,
Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-04-06 12:51 ` Daniel Borkmann
(?)
@ 2017-05-06 16:48 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 16:48 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 I could find the description of these
instructions please?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 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 purpose to test the JIT with corner cases. If you see a useful
> test missing, please send a patch for it, so all other JITs can benefit
> from this as well. For extracting disassembly from a generated test case,
> check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 16:48 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 16:48 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 I could find the description of these
instructions please?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 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 purpose to test the JIT with corner cases. If you see a useful
> test missing, please send a patch for it, so all other JITs can benefit
> from this as well. For extracting disassembly from a generated test case,
> check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 16:48 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 16:48 UTC (permalink / raw)
To: linux-arm-kernel
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 I could find the description of these
instructions please?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 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 purpose to test the JIT with corner cases. If you see a useful
> test missing, please send a patch for it, so all other JITs can benefit
> from this as well. For extracting disassembly from a generated test case,
> check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-05-06 16:48 ` Shubham Bansal
(?)
@ 2017-05-06 18:38 ` David Miller
-1 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-05-06 18:38 UTC (permalink / raw)
To: illusionist.neo
Cc: daniel, keescook, mgherzan, netdev, kernel-hardening,
linux-arm-kernel, ast
From: Shubham Bansal <illusionist.neo@gmail.com>
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_LD
instruction which indicate an SKB load is to be performed.
You never need to ask what a BPF instruction does, it is clear
defined in the BPF interperter found in kernel/bpf/core.c
Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 18:38 ` David Miller
0 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-05-06 18:38 UTC (permalink / raw)
To: illusionist.neo
Cc: daniel, keescook, mgherzan, netdev, kernel-hardening,
linux-arm-kernel, ast
From: Shubham Bansal <illusionist.neo@gmail.com>
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_LD
instruction which indicate an SKB load is to be performed.
You never need to ask what a BPF instruction does, it is clear
defined in the BPF interperter found in kernel/bpf/core.c
Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 18:38 ` David Miller
0 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-05-06 18:38 UTC (permalink / raw)
To: linux-arm-kernel
From: Shubham Bansal <illusionist.neo@gmail.com>
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_LD
instruction which indicate an SKB load is to be performed.
You never need to ask what a BPF instruction does, it is clear
defined in the BPF interperter found in kernel/bpf/core.c
Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-05-06 18:38 ` David Miller
(?)
@ 2017-05-06 20:27 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 20:27 UTC (permalink / raw)
To: David Miller
Cc: Kees Cook, Daniel Borkmann, kernel-hardening,
Network Development, ast, Mircea Gherzan, linux-arm-kernel
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 and this code
clearly is overwriting that pointer which makes that pointer useless
for future usage. It clearly looks like a bug.
2. At line 256, " emit(A64_LDR64(prg, tmp, r3), ctx); ".
This line of code is used to load an array( of pointers ) element,
where r3 is used as an index of that array. Shouldn't it be be
arithmetic left shifted by 3 or multiplied by 8 to get the right
address in that array of pointers ?
Apologies if any of the above question is stupid to ask.
Best,
Shubham
Best,
Shubham Bansal
On Sun, May 7, 2017 at 12:08 AM, David Miller <davem@davemloft.net> wrote:
> From: Shubham Bansal <illusionist.neo@gmail.com>
> 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_LD
> instruction which indicate an SKB load is to be performed.
>
> You never need to ask what a BPF instruction does, it is clear
> defined in the BPF interperter found in kernel/bpf/core.c
>
> Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 20:27 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 20:27 UTC (permalink / raw)
To: David Miller
Cc: Daniel Borkmann, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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 and this code
clearly is overwriting that pointer which makes that pointer useless
for future usage. It clearly looks like a bug.
2. At line 256, " emit(A64_LDR64(prg, tmp, r3), ctx); ".
This line of code is used to load an array( of pointers ) element,
where r3 is used as an index of that array. Shouldn't it be be
arithmetic left shifted by 3 or multiplied by 8 to get the right
address in that array of pointers ?
Apologies if any of the above question is stupid to ask.
Best,
Shubham
Best,
Shubham Bansal
On Sun, May 7, 2017 at 12:08 AM, David Miller <davem@davemloft.net> wrote:
> From: Shubham Bansal <illusionist.neo@gmail.com>
> 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_LD
> instruction which indicate an SKB load is to be performed.
>
> You never need to ask what a BPF instruction does, it is clear
> defined in the BPF interperter found in kernel/bpf/core.c
>
> Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 20:27 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 20:27 UTC (permalink / raw)
To: linux-arm-kernel
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 and this code
clearly is overwriting that pointer which makes that pointer useless
for future usage. It clearly looks like a bug.
2. At line 256, " emit(A64_LDR64(prg, tmp, r3), ctx); ".
This line of code is used to load an array( of pointers ) element,
where r3 is used as an index of that array. Shouldn't it be be
arithmetic left shifted by 3 or multiplied by 8 to get the right
address in that array of pointers ?
Apologies if any of the above question is stupid to ask.
Best,
Shubham
Best,
Shubham Bansal
On Sun, May 7, 2017 at 12:08 AM, David Miller <davem@davemloft.net> wrote:
> From: Shubham Bansal <illusionist.neo@gmail.com>
> 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_LD
> instruction which indicate an SKB load is to be performed.
>
> You never need to ask what a BPF instruction does, it is clear
> defined in the BPF interperter found in kernel/bpf/core.c
>
> Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-05-06 20:27 ` Shubham Bansal
(?)
@ 2017-05-06 22:17 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 22:17 UTC (permalink / raw)
To: David Miller
Cc: Daniel Borkmann, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
Okay. My mistake. I just checked the verify function.
Apologies.
Best,
Shubham Bansal
On Sun, May 7, 2017 at 1:57 AM, Shubham Bansal
<illusionist.neo@gmail.com> 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]; /* 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 and this code
> clearly is overwriting that pointer which makes that pointer useless
> for future usage. It clearly looks like a bug.
>
> 2. At line 256, " emit(A64_LDR64(prg, tmp, r3), ctx); ".
> This line of code is used to load an array( of pointers ) element,
> where r3 is used as an index of that array. Shouldn't it be be
> arithmetic left shifted by 3 or multiplied by 8 to get the right
> address in that array of pointers ?
>
> Apologies if any of the above question is stupid to ask.
>
> Best,
> Shubham
> Best,
> Shubham Bansal
>
>
> On Sun, May 7, 2017 at 12:08 AM, David Miller <davem@davemloft.net> wrote:
>> From: Shubham Bansal <illusionist.neo@gmail.com>
>> 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_LD
>> instruction which indicate an SKB load is to be performed.
>>
>> You never need to ask what a BPF instruction does, it is clear
>> defined in the BPF interperter found in kernel/bpf/core.c
>>
>> Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 22:17 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 22:17 UTC (permalink / raw)
To: David Miller
Cc: Daniel Borkmann, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
Okay. My mistake. I just checked the verify function.
Apologies.
Best,
Shubham Bansal
On Sun, May 7, 2017 at 1:57 AM, Shubham Bansal
<illusionist.neo@gmail.com> 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]; /* 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 and this code
> clearly is overwriting that pointer which makes that pointer useless
> for future usage. It clearly looks like a bug.
>
> 2. At line 256, " emit(A64_LDR64(prg, tmp, r3), ctx); ".
> This line of code is used to load an array( of pointers ) element,
> where r3 is used as an index of that array. Shouldn't it be be
> arithmetic left shifted by 3 or multiplied by 8 to get the right
> address in that array of pointers ?
>
> Apologies if any of the above question is stupid to ask.
>
> Best,
> Shubham
> Best,
> Shubham Bansal
>
>
> On Sun, May 7, 2017 at 12:08 AM, David Miller <davem@davemloft.net> wrote:
>> From: Shubham Bansal <illusionist.neo@gmail.com>
>> 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_LD
>> instruction which indicate an SKB load is to be performed.
>>
>> You never need to ask what a BPF instruction does, it is clear
>> defined in the BPF interperter found in kernel/bpf/core.c
>>
>> Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-06 22:17 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-06 22:17 UTC (permalink / raw)
To: linux-arm-kernel
Okay. My mistake. I just checked the verify function.
Apologies.
Best,
Shubham Bansal
On Sun, May 7, 2017 at 1:57 AM, Shubham Bansal
<illusionist.neo@gmail.com> 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]; /* 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 and this code
> clearly is overwriting that pointer which makes that pointer useless
> for future usage. It clearly looks like a bug.
>
> 2. At line 256, " emit(A64_LDR64(prg, tmp, r3), ctx); ".
> This line of code is used to load an array( of pointers ) element,
> where r3 is used as an index of that array. Shouldn't it be be
> arithmetic left shifted by 3 or multiplied by 8 to get the right
> address in that array of pointers ?
>
> Apologies if any of the above question is stupid to ask.
>
> Best,
> Shubham
> Best,
> Shubham Bansal
>
>
> On Sun, May 7, 2017 at 12:08 AM, David Miller <davem@davemloft.net> wrote:
>> From: Shubham Bansal <illusionist.neo@gmail.com>
>> 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_LD
>> instruction which indicate an SKB load is to be performed.
>>
>> You never need to ask what a BPF instruction does, it is clear
>> defined in the BPF interperter found in kernel/bpf/core.c
>>
>> Look for the case statement LD_ABS_W and friends in __bpf_prog_run().
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-04-06 12:51 ` Daniel Borkmann
(?)
@ 2017-05-09 20:12 ` Shubham Bansal
-1 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-09 20:12 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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: 00000000: f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
JIT code: 00000010: 08 42 8d e5 00 00 20 e0 01 10 21 e0 20 62 9d e5
JIT code: 00000020: 20 72 9d e5 06 70 27 e0 20 72 8d e5 24 62 9d e5
JIT code: 00000030: 24 72 9d e5 06 70 27 e0 24 72 8d e5 00 40 a0 e1
JIT code: 00000040: 01 50 a0 e1 01 00 a0 e3 00 10 a0 e3 20 02 8d e5
JIT code: 00000050: 24 12 8d e5 02 00 a0 e3 00 10 a0 e3 20 62 9d e5
JIT code: 00000060: 06 00 80 e0 00 10 a0 e3 00 00 60 e2 00 10 a0 e3
JIT code: 00000070: 20 02 8d e5 24 12 8d e5 54 40 90 e5 20 62 9d e5
JIT code: 00000080: 06 00 80 e0 00 10 a0 e3 20 02 8d e5 24 12 8d e5
JIT code: 00000090: 04 00 a0 e1 01 10 a0 e3 20 62 9d e5 06 10 81 e0
JIT code: 000000a0: 01 20 a0 e3 04 32 8d e2 bc 68 0a e3 11 60 48 e3
JIT code: 000000b0: 36 ff 2f e1 01 10 21 e0 00 00 50 e3 04 00 00 0a
JIT code: 000000c0: 00 00 d0 e5 01 00 00 ea 40 d2 8d e2 f0 05 bd e8
JIT code: 000000d0: 1e ff 2f e1
jited:1
Unhandled fault: page domain fault (0x01b) at 0x00000051
pgd = 871d0000
[00000051] *pgd=671b7831, *pte=00000000, *ppte=00000000
Internal error: : 1b [#1] SMP ARM
Modules linked in: test_bpf(+)
CPU: 0 PID: 730 Comm: insmod Not tainted 4.11.0+ #5
Hardware name: ARM-Versatile Express
task: 87023700 task.stack: 8718a000
PC is at 0x7f15a8b4
LR is at test_bpf_init+0x5bc/0x1000 [test_bpf]
pc : [<7f15a8b4>] lr : [<7f1575bc>] psr: 80000013
sp : 8718bd7c ip : 00000015 fp : 7f005008
r10: 7f005094 r9 : 893ba020 r8 : 893ba000
r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 00000000
r3 : 7f15a83c r2 : 893ba020 r1 : 00000000 r0 : fffffffd
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 671d0059 DAC: 00000051
Process insmod (pid: 730, stack limit = 0x8718a210)
Stack: (0x8718bd7c to 0x8718c000)
bd60: 00000000
bd80: 00002710 870db300 c302e7e8 7f004010 893ba000 7f005094 00000000 00000000
bda0: 00000000 00000000 00000000 00000001 00000001 00000000 014000c0 00150628
bdc0: 7f0050ac 7f154840 1234aaaa 1234aaab c302e7e8 0000000f 00000000 893ba000
bde0: 0000000b 7f004010 87fd54a0 ffffe000 7f157000 00000000 871b6fc0 00000001
be00: 78e4905c 00000024 7f154640 8010179c 80a06544 8718a000 00000001 80a54980
be20: 80a3066c 00000007 809685c0 80a54700 80a54700 07551000 80a54700 60070013
be40: 7f154640 801f3fc8 78e4905c 7f154640 00000001 871b6fe4 7f154640 00000001
be60: 871b6b00 00000001 78e4905c 801eaa94 00000001 871b6fe4 8718bf44 00000001
be80: 871b6fe4 80196e4c 7f15464c 00007fff 7f154640 80193f10 87127000 7f154640
bea0: 7f154688 80703800 7f154770 807037e4 8081b184 807bec60 807becc4 807bec6c
bec0: 7f15481c 8010c1b8 93600000 76ed8028 00000f60 00000000 00000000 00000000
bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00003f80
bf20: 76f5cf88 00000000 93684f80 8718a000 00160fda 00000051 00000000 801973b0
bf40: 87671a00 93501000 00183f80 93684760 93684574 936788e0 00155000 00155290
bf60: 00000000 00000000 00000000 00001f64 00000032 00000033 0000001d 00000000
bf80: 00000017 00000000 00000000 00183f80 756e694c 00000080 80107684 fffffffd
bfa0: 00000000 801074c0 00000000 00183f80 76dd9008 00183f80 00160fda 00000000
bfc0: 00000000 00183f80 756e694c 00000080 00000001 7eabae2c 00172f8c 00000000
bfe0: 7eabaae0 7eabaad0 0004017f 00013172 60070030 76dd9008 00000000 00000000
[<7f1575bc>] (test_bpf_init [test_bpf]) from [<7f157000>]
(test_bpf_init+0x0/0x1000 [test_bpf])
[<7f157000>] (test_bpf_init [test_bpf]) from [<78e4905c>] (0x78e4905c)
Code: e2600000 e3a01000 e58d0220 e58d1224 (e5904054)
---[ end trace a36398923b914fe2 ]---
Segmentation fault
Why is trying to execute TAX which is a cBPF instruction?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 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 purpose to test the JIT with corner cases. If you see a useful
> test missing, please send a patch for it, so all other JITs can benefit
> from this as well. For extracting disassembly from a generated test case,
> check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-09 20:12 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-09 20:12 UTC (permalink / raw)
To: Daniel Borkmann
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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: 00000000: f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
JIT code: 00000010: 08 42 8d e5 00 00 20 e0 01 10 21 e0 20 62 9d e5
JIT code: 00000020: 20 72 9d e5 06 70 27 e0 20 72 8d e5 24 62 9d e5
JIT code: 00000030: 24 72 9d e5 06 70 27 e0 24 72 8d e5 00 40 a0 e1
JIT code: 00000040: 01 50 a0 e1 01 00 a0 e3 00 10 a0 e3 20 02 8d e5
JIT code: 00000050: 24 12 8d e5 02 00 a0 e3 00 10 a0 e3 20 62 9d e5
JIT code: 00000060: 06 00 80 e0 00 10 a0 e3 00 00 60 e2 00 10 a0 e3
JIT code: 00000070: 20 02 8d e5 24 12 8d e5 54 40 90 e5 20 62 9d e5
JIT code: 00000080: 06 00 80 e0 00 10 a0 e3 20 02 8d e5 24 12 8d e5
JIT code: 00000090: 04 00 a0 e1 01 10 a0 e3 20 62 9d e5 06 10 81 e0
JIT code: 000000a0: 01 20 a0 e3 04 32 8d e2 bc 68 0a e3 11 60 48 e3
JIT code: 000000b0: 36 ff 2f e1 01 10 21 e0 00 00 50 e3 04 00 00 0a
JIT code: 000000c0: 00 00 d0 e5 01 00 00 ea 40 d2 8d e2 f0 05 bd e8
JIT code: 000000d0: 1e ff 2f e1
jited:1
Unhandled fault: page domain fault (0x01b) at 0x00000051
pgd = 871d0000
[00000051] *pgd=671b7831, *pte=00000000, *ppte=00000000
Internal error: : 1b [#1] SMP ARM
Modules linked in: test_bpf(+)
CPU: 0 PID: 730 Comm: insmod Not tainted 4.11.0+ #5
Hardware name: ARM-Versatile Express
task: 87023700 task.stack: 8718a000
PC is at 0x7f15a8b4
LR is at test_bpf_init+0x5bc/0x1000 [test_bpf]
pc : [<7f15a8b4>] lr : [<7f1575bc>] psr: 80000013
sp : 8718bd7c ip : 00000015 fp : 7f005008
r10: 7f005094 r9 : 893ba020 r8 : 893ba000
r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 00000000
r3 : 7f15a83c r2 : 893ba020 r1 : 00000000 r0 : fffffffd
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 671d0059 DAC: 00000051
Process insmod (pid: 730, stack limit = 0x8718a210)
Stack: (0x8718bd7c to 0x8718c000)
bd60: 00000000
bd80: 00002710 870db300 c302e7e8 7f004010 893ba000 7f005094 00000000 00000000
bda0: 00000000 00000000 00000000 00000001 00000001 00000000 014000c0 00150628
bdc0: 7f0050ac 7f154840 1234aaaa 1234aaab c302e7e8 0000000f 00000000 893ba000
bde0: 0000000b 7f004010 87fd54a0 ffffe000 7f157000 00000000 871b6fc0 00000001
be00: 78e4905c 00000024 7f154640 8010179c 80a06544 8718a000 00000001 80a54980
be20: 80a3066c 00000007 809685c0 80a54700 80a54700 07551000 80a54700 60070013
be40: 7f154640 801f3fc8 78e4905c 7f154640 00000001 871b6fe4 7f154640 00000001
be60: 871b6b00 00000001 78e4905c 801eaa94 00000001 871b6fe4 8718bf44 00000001
be80: 871b6fe4 80196e4c 7f15464c 00007fff 7f154640 80193f10 87127000 7f154640
bea0: 7f154688 80703800 7f154770 807037e4 8081b184 807bec60 807becc4 807bec6c
bec0: 7f15481c 8010c1b8 93600000 76ed8028 00000f60 00000000 00000000 00000000
bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00003f80
bf20: 76f5cf88 00000000 93684f80 8718a000 00160fda 00000051 00000000 801973b0
bf40: 87671a00 93501000 00183f80 93684760 93684574 936788e0 00155000 00155290
bf60: 00000000 00000000 00000000 00001f64 00000032 00000033 0000001d 00000000
bf80: 00000017 00000000 00000000 00183f80 756e694c 00000080 80107684 fffffffd
bfa0: 00000000 801074c0 00000000 00183f80 76dd9008 00183f80 00160fda 00000000
bfc0: 00000000 00183f80 756e694c 00000080 00000001 7eabae2c 00172f8c 00000000
bfe0: 7eabaae0 7eabaad0 0004017f 00013172 60070030 76dd9008 00000000 00000000
[<7f1575bc>] (test_bpf_init [test_bpf]) from [<7f157000>]
(test_bpf_init+0x0/0x1000 [test_bpf])
[<7f157000>] (test_bpf_init [test_bpf]) from [<78e4905c>] (0x78e4905c)
Code: e2600000 e3a01000 e58d0220 e58d1224 (e5904054)
---[ end trace a36398923b914fe2 ]---
Segmentation fault
Why is trying to execute TAX which is a cBPF instruction?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 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 purpose to test the JIT with corner cases. If you see a useful
> test missing, please send a patch for it, so all other JITs can benefit
> from this as well. For extracting disassembly from a generated test case,
> check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-09 20:12 ` Shubham Bansal
0 siblings, 0 replies; 67+ messages in thread
From: Shubham Bansal @ 2017-05-09 20:12 UTC (permalink / raw)
To: linux-arm-kernel
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: 00000000: f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
JIT code: 00000010: 08 42 8d e5 00 00 20 e0 01 10 21 e0 20 62 9d e5
JIT code: 00000020: 20 72 9d e5 06 70 27 e0 20 72 8d e5 24 62 9d e5
JIT code: 00000030: 24 72 9d e5 06 70 27 e0 24 72 8d e5 00 40 a0 e1
JIT code: 00000040: 01 50 a0 e1 01 00 a0 e3 00 10 a0 e3 20 02 8d e5
JIT code: 00000050: 24 12 8d e5 02 00 a0 e3 00 10 a0 e3 20 62 9d e5
JIT code: 00000060: 06 00 80 e0 00 10 a0 e3 00 00 60 e2 00 10 a0 e3
JIT code: 00000070: 20 02 8d e5 24 12 8d e5 54 40 90 e5 20 62 9d e5
JIT code: 00000080: 06 00 80 e0 00 10 a0 e3 20 02 8d e5 24 12 8d e5
JIT code: 00000090: 04 00 a0 e1 01 10 a0 e3 20 62 9d e5 06 10 81 e0
JIT code: 000000a0: 01 20 a0 e3 04 32 8d e2 bc 68 0a e3 11 60 48 e3
JIT code: 000000b0: 36 ff 2f e1 01 10 21 e0 00 00 50 e3 04 00 00 0a
JIT code: 000000c0: 00 00 d0 e5 01 00 00 ea 40 d2 8d e2 f0 05 bd e8
JIT code: 000000d0: 1e ff 2f e1
jited:1
Unhandled fault: page domain fault (0x01b) at 0x00000051
pgd = 871d0000
[00000051] *pgd=671b7831, *pte=00000000, *ppte=00000000
Internal error: : 1b [#1] SMP ARM
Modules linked in: test_bpf(+)
CPU: 0 PID: 730 Comm: insmod Not tainted 4.11.0+ #5
Hardware name: ARM-Versatile Express
task: 87023700 task.stack: 8718a000
PC is at 0x7f15a8b4
LR is at test_bpf_init+0x5bc/0x1000 [test_bpf]
pc : [<7f15a8b4>] lr : [<7f1575bc>] psr: 80000013
sp : 8718bd7c ip : 00000015 fp : 7f005008
r10: 7f005094 r9 : 893ba020 r8 : 893ba000
r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 00000000
r3 : 7f15a83c r2 : 893ba020 r1 : 00000000 r0 : fffffffd
Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control: 10c5387d Table: 671d0059 DAC: 00000051
Process insmod (pid: 730, stack limit = 0x8718a210)
Stack: (0x8718bd7c to 0x8718c000)
bd60: 00000000
bd80: 00002710 870db300 c302e7e8 7f004010 893ba000 7f005094 00000000 00000000
bda0: 00000000 00000000 00000000 00000001 00000001 00000000 014000c0 00150628
bdc0: 7f0050ac 7f154840 1234aaaa 1234aaab c302e7e8 0000000f 00000000 893ba000
bde0: 0000000b 7f004010 87fd54a0 ffffe000 7f157000 00000000 871b6fc0 00000001
be00: 78e4905c 00000024 7f154640 8010179c 80a06544 8718a000 00000001 80a54980
be20: 80a3066c 00000007 809685c0 80a54700 80a54700 07551000 80a54700 60070013
be40: 7f154640 801f3fc8 78e4905c 7f154640 00000001 871b6fe4 7f154640 00000001
be60: 871b6b00 00000001 78e4905c 801eaa94 00000001 871b6fe4 8718bf44 00000001
be80: 871b6fe4 80196e4c 7f15464c 00007fff 7f154640 80193f10 87127000 7f154640
bea0: 7f154688 80703800 7f154770 807037e4 8081b184 807bec60 807becc4 807bec6c
bec0: 7f15481c 8010c1b8 93600000 76ed8028 00000f60 00000000 00000000 00000000
bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00003f80
bf20: 76f5cf88 00000000 93684f80 8718a000 00160fda 00000051 00000000 801973b0
bf40: 87671a00 93501000 00183f80 93684760 93684574 936788e0 00155000 00155290
bf60: 00000000 00000000 00000000 00001f64 00000032 00000033 0000001d 00000000
bf80: 00000017 00000000 00000000 00183f80 756e694c 00000080 80107684 fffffffd
bfa0: 00000000 801074c0 00000000 00183f80 76dd9008 00183f80 00160fda 00000000
bfc0: 00000000 00183f80 756e694c 00000080 00000001 7eabae2c 00172f8c 00000000
bfe0: 7eabaae0 7eabaad0 0004017f 00013172 60070030 76dd9008 00000000 00000000
[<7f1575bc>] (test_bpf_init [test_bpf]) from [<7f157000>]
(test_bpf_init+0x0/0x1000 [test_bpf])
[<7f157000>] (test_bpf_init [test_bpf]) from [<78e4905c>] (0x78e4905c)
Code: e2600000 e3a01000 e58d0220 e58d1224 (e5904054)
---[ end trace a36398923b914fe2 ]---
Segmentation fault
Why is trying to execute TAX which is a cBPF instruction?
Best,
Shubham Bansal
On Thu, Apr 6, 2017 at 6:21 PM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> 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 purpose to test the JIT with corner cases. If you see a useful
> test missing, please send a patch for it, so all other JITs can benefit
> from this as well. For extracting disassembly from a generated test case,
> check out bpf_jit_disasm (Documentation/networking/filter.txt +486).
>
> Thanks,
> Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-05-09 20:12 ` Shubham Bansal
(?)
@ 2017-05-09 20:19 ` David Miller
-1 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-05-09 20:19 UTC (permalink / raw)
To: illusionist.neo
Cc: daniel, keescook, mgherzan, netdev, kernel-hardening,
linux-arm-kernel, ast
From: Shubham Bansal <illusionist.neo@gmail.com>
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-09 20:19 ` David Miller
0 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-05-09 20:19 UTC (permalink / raw)
To: illusionist.neo
Cc: daniel, keescook, mgherzan, netdev, kernel-hardening,
linux-arm-kernel, ast
From: Shubham Bansal <illusionist.neo@gmail.com>
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-09 20:19 ` David Miller
0 siblings, 0 replies; 67+ messages in thread
From: David Miller @ 2017-05-09 20:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Shubham Bansal <illusionist.neo@gmail.com>
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
2017-05-09 20:12 ` Shubham Bansal
(?)
@ 2017-05-09 20:25 ` Daniel Borkmann
-1 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-05-09 20:25 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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: 00000000: f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
> JIT code: 00000010: 08 42 8d e5 00 00 20 e0 01 10 21 e0 20 62 9d e5
> JIT code: 00000020: 20 72 9d e5 06 70 27 e0 20 72 8d e5 24 62 9d e5
> JIT code: 00000030: 24 72 9d e5 06 70 27 e0 24 72 8d e5 00 40 a0 e1
> JIT code: 00000040: 01 50 a0 e1 01 00 a0 e3 00 10 a0 e3 20 02 8d e5
> JIT code: 00000050: 24 12 8d e5 02 00 a0 e3 00 10 a0 e3 20 62 9d e5
> JIT code: 00000060: 06 00 80 e0 00 10 a0 e3 00 00 60 e2 00 10 a0 e3
> JIT code: 00000070: 20 02 8d e5 24 12 8d e5 54 40 90 e5 20 62 9d e5
> JIT code: 00000080: 06 00 80 e0 00 10 a0 e3 20 02 8d e5 24 12 8d e5
> JIT code: 00000090: 04 00 a0 e1 01 10 a0 e3 20 62 9d e5 06 10 81 e0
> JIT code: 000000a0: 01 20 a0 e3 04 32 8d e2 bc 68 0a e3 11 60 48 e3
> JIT code: 000000b0: 36 ff 2f e1 01 10 21 e0 00 00 50 e3 04 00 00 0a
> JIT code: 000000c0: 00 00 d0 e5 01 00 00 ea 40 d2 8d e2 f0 05 bd e8
> JIT code: 000000d0: 1e ff 2f e1
> jited:1
> Unhandled fault: page domain fault (0x01b) at 0x00000051
> pgd = 871d0000
> [00000051] *pgd=671b7831, *pte=00000000, *ppte=00000000
> Internal error: : 1b [#1] SMP ARM
> Modules linked in: test_bpf(+)
> CPU: 0 PID: 730 Comm: insmod Not tainted 4.11.0+ #5
> Hardware name: ARM-Versatile Express
> task: 87023700 task.stack: 8718a000
> PC is at 0x7f15a8b4
> LR is at test_bpf_init+0x5bc/0x1000 [test_bpf]
> pc : [<7f15a8b4>] lr : [<7f1575bc>] psr: 80000013
> sp : 8718bd7c ip : 00000015 fp : 7f005008
> r10: 7f005094 r9 : 893ba020 r8 : 893ba000
> r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 00000000
> r3 : 7f15a83c r2 : 893ba020 r1 : 00000000 r0 : fffffffd
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 671d0059 DAC: 00000051
> Process insmod (pid: 730, stack limit = 0x8718a210)
> Stack: (0x8718bd7c to 0x8718c000)
> bd60: 00000000
> bd80: 00002710 870db300 c302e7e8 7f004010 893ba000 7f005094 00000000 00000000
> bda0: 00000000 00000000 00000000 00000001 00000001 00000000 014000c0 00150628
> bdc0: 7f0050ac 7f154840 1234aaaa 1234aaab c302e7e8 0000000f 00000000 893ba000
> bde0: 0000000b 7f004010 87fd54a0 ffffe000 7f157000 00000000 871b6fc0 00000001
> be00: 78e4905c 00000024 7f154640 8010179c 80a06544 8718a000 00000001 80a54980
> be20: 80a3066c 00000007 809685c0 80a54700 80a54700 07551000 80a54700 60070013
> be40: 7f154640 801f3fc8 78e4905c 7f154640 00000001 871b6fe4 7f154640 00000001
> be60: 871b6b00 00000001 78e4905c 801eaa94 00000001 871b6fe4 8718bf44 00000001
> be80: 871b6fe4 80196e4c 7f15464c 00007fff 7f154640 80193f10 87127000 7f154640
> bea0: 7f154688 80703800 7f154770 807037e4 8081b184 807bec60 807becc4 807bec6c
> bec0: 7f15481c 8010c1b8 93600000 76ed8028 00000f60 00000000 00000000 00000000
> bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00003f80
> bf20: 76f5cf88 00000000 93684f80 8718a000 00160fda 00000051 00000000 801973b0
> bf40: 87671a00 93501000 00183f80 93684760 93684574 936788e0 00155000 00155290
> bf60: 00000000 00000000 00000000 00001f64 00000032 00000033 0000001d 00000000
> bf80: 00000017 00000000 00000000 00183f80 756e694c 00000080 80107684 fffffffd
> bfa0: 00000000 801074c0 00000000 00183f80 76dd9008 00183f80 00160fda 00000000
> bfc0: 00000000 00183f80 756e694c 00000080 00000001 7eabae2c 00172f8c 00000000
> bfe0: 7eabaae0 7eabaad0 0004017f 00013172 60070030 76dd9008 00000000 00000000
> [<7f1575bc>] (test_bpf_init [test_bpf]) from [<7f157000>]
> (test_bpf_init+0x0/0x1000 [test_bpf])
> [<7f157000>] (test_bpf_init [test_bpf]) from [<78e4905c>] (0x78e4905c)
> Code: e2600000 e3a01000 e58d0220 e58d1224 (e5904054)
> ---[ end trace a36398923b914fe2 ]---
> Segmentation fault
>
> Why is trying to execute TAX which is a cBPF instruction?
Kernel translates this to eBPF internally (bpf_prepare_filter() ->
bpf_migrate_filter()), no cBPF will see the JIT directly.
Is your implementation still using bpf_jit_compile() callback as
opposed to bpf_int_jit_compile()?!
Cheers,
Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* [kernel-hardening] Re: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-09 20:25 ` Daniel Borkmann
0 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-05-09 20:25 UTC (permalink / raw)
To: Shubham Bansal
Cc: David Miller, Kees Cook, Mircea Gherzan, Network Development,
kernel-hardening, linux-arm-kernel, ast
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: 00000000: f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
> JIT code: 00000010: 08 42 8d e5 00 00 20 e0 01 10 21 e0 20 62 9d e5
> JIT code: 00000020: 20 72 9d e5 06 70 27 e0 20 72 8d e5 24 62 9d e5
> JIT code: 00000030: 24 72 9d e5 06 70 27 e0 24 72 8d e5 00 40 a0 e1
> JIT code: 00000040: 01 50 a0 e1 01 00 a0 e3 00 10 a0 e3 20 02 8d e5
> JIT code: 00000050: 24 12 8d e5 02 00 a0 e3 00 10 a0 e3 20 62 9d e5
> JIT code: 00000060: 06 00 80 e0 00 10 a0 e3 00 00 60 e2 00 10 a0 e3
> JIT code: 00000070: 20 02 8d e5 24 12 8d e5 54 40 90 e5 20 62 9d e5
> JIT code: 00000080: 06 00 80 e0 00 10 a0 e3 20 02 8d e5 24 12 8d e5
> JIT code: 00000090: 04 00 a0 e1 01 10 a0 e3 20 62 9d e5 06 10 81 e0
> JIT code: 000000a0: 01 20 a0 e3 04 32 8d e2 bc 68 0a e3 11 60 48 e3
> JIT code: 000000b0: 36 ff 2f e1 01 10 21 e0 00 00 50 e3 04 00 00 0a
> JIT code: 000000c0: 00 00 d0 e5 01 00 00 ea 40 d2 8d e2 f0 05 bd e8
> JIT code: 000000d0: 1e ff 2f e1
> jited:1
> Unhandled fault: page domain fault (0x01b) at 0x00000051
> pgd = 871d0000
> [00000051] *pgd=671b7831, *pte=00000000, *ppte=00000000
> Internal error: : 1b [#1] SMP ARM
> Modules linked in: test_bpf(+)
> CPU: 0 PID: 730 Comm: insmod Not tainted 4.11.0+ #5
> Hardware name: ARM-Versatile Express
> task: 87023700 task.stack: 8718a000
> PC is at 0x7f15a8b4
> LR is at test_bpf_init+0x5bc/0x1000 [test_bpf]
> pc : [<7f15a8b4>] lr : [<7f1575bc>] psr: 80000013
> sp : 8718bd7c ip : 00000015 fp : 7f005008
> r10: 7f005094 r9 : 893ba020 r8 : 893ba000
> r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 00000000
> r3 : 7f15a83c r2 : 893ba020 r1 : 00000000 r0 : fffffffd
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 671d0059 DAC: 00000051
> Process insmod (pid: 730, stack limit = 0x8718a210)
> Stack: (0x8718bd7c to 0x8718c000)
> bd60: 00000000
> bd80: 00002710 870db300 c302e7e8 7f004010 893ba000 7f005094 00000000 00000000
> bda0: 00000000 00000000 00000000 00000001 00000001 00000000 014000c0 00150628
> bdc0: 7f0050ac 7f154840 1234aaaa 1234aaab c302e7e8 0000000f 00000000 893ba000
> bde0: 0000000b 7f004010 87fd54a0 ffffe000 7f157000 00000000 871b6fc0 00000001
> be00: 78e4905c 00000024 7f154640 8010179c 80a06544 8718a000 00000001 80a54980
> be20: 80a3066c 00000007 809685c0 80a54700 80a54700 07551000 80a54700 60070013
> be40: 7f154640 801f3fc8 78e4905c 7f154640 00000001 871b6fe4 7f154640 00000001
> be60: 871b6b00 00000001 78e4905c 801eaa94 00000001 871b6fe4 8718bf44 00000001
> be80: 871b6fe4 80196e4c 7f15464c 00007fff 7f154640 80193f10 87127000 7f154640
> bea0: 7f154688 80703800 7f154770 807037e4 8081b184 807bec60 807becc4 807bec6c
> bec0: 7f15481c 8010c1b8 93600000 76ed8028 00000f60 00000000 00000000 00000000
> bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00003f80
> bf20: 76f5cf88 00000000 93684f80 8718a000 00160fda 00000051 00000000 801973b0
> bf40: 87671a00 93501000 00183f80 93684760 93684574 936788e0 00155000 00155290
> bf60: 00000000 00000000 00000000 00001f64 00000032 00000033 0000001d 00000000
> bf80: 00000017 00000000 00000000 00183f80 756e694c 00000080 80107684 fffffffd
> bfa0: 00000000 801074c0 00000000 00183f80 76dd9008 00183f80 00160fda 00000000
> bfc0: 00000000 00183f80 756e694c 00000080 00000001 7eabae2c 00172f8c 00000000
> bfe0: 7eabaae0 7eabaad0 0004017f 00013172 60070030 76dd9008 00000000 00000000
> [<7f1575bc>] (test_bpf_init [test_bpf]) from [<7f157000>]
> (test_bpf_init+0x0/0x1000 [test_bpf])
> [<7f157000>] (test_bpf_init [test_bpf]) from [<78e4905c>] (0x78e4905c)
> Code: e2600000 e3a01000 e58d0220 e58d1224 (e5904054)
> ---[ end trace a36398923b914fe2 ]---
> Segmentation fault
>
> Why is trying to execute TAX which is a cBPF instruction?
Kernel translates this to eBPF internally (bpf_prepare_filter() ->
bpf_migrate_filter()), no cBPF will see the JIT directly.
Is your implementation still using bpf_jit_compile() callback as
opposed to bpf_int_jit_compile()?!
Cheers,
Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread
* arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
@ 2017-05-09 20:25 ` Daniel Borkmann
0 siblings, 0 replies; 67+ messages in thread
From: Daniel Borkmann @ 2017-05-09 20:25 UTC (permalink / raw)
To: linux-arm-kernel
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: 00000000: f0 05 2d e9 40 d2 4d e2 00 40 a0 e3 0c 42 8d e5
> JIT code: 00000010: 08 42 8d e5 00 00 20 e0 01 10 21 e0 20 62 9d e5
> JIT code: 00000020: 20 72 9d e5 06 70 27 e0 20 72 8d e5 24 62 9d e5
> JIT code: 00000030: 24 72 9d e5 06 70 27 e0 24 72 8d e5 00 40 a0 e1
> JIT code: 00000040: 01 50 a0 e1 01 00 a0 e3 00 10 a0 e3 20 02 8d e5
> JIT code: 00000050: 24 12 8d e5 02 00 a0 e3 00 10 a0 e3 20 62 9d e5
> JIT code: 00000060: 06 00 80 e0 00 10 a0 e3 00 00 60 e2 00 10 a0 e3
> JIT code: 00000070: 20 02 8d e5 24 12 8d e5 54 40 90 e5 20 62 9d e5
> JIT code: 00000080: 06 00 80 e0 00 10 a0 e3 20 02 8d e5 24 12 8d e5
> JIT code: 00000090: 04 00 a0 e1 01 10 a0 e3 20 62 9d e5 06 10 81 e0
> JIT code: 000000a0: 01 20 a0 e3 04 32 8d e2 bc 68 0a e3 11 60 48 e3
> JIT code: 000000b0: 36 ff 2f e1 01 10 21 e0 00 00 50 e3 04 00 00 0a
> JIT code: 000000c0: 00 00 d0 e5 01 00 00 ea 40 d2 8d e2 f0 05 bd e8
> JIT code: 000000d0: 1e ff 2f e1
> jited:1
> Unhandled fault: page domain fault (0x01b) at 0x00000051
> pgd = 871d0000
> [00000051] *pgd=671b7831, *pte=00000000, *ppte=00000000
> Internal error: : 1b [#1] SMP ARM
> Modules linked in: test_bpf(+)
> CPU: 0 PID: 730 Comm: insmod Not tainted 4.11.0+ #5
> Hardware name: ARM-Versatile Express
> task: 87023700 task.stack: 8718a000
> PC is at 0x7f15a8b4
> LR is at test_bpf_init+0x5bc/0x1000 [test_bpf]
> pc : [<7f15a8b4>] lr : [<7f1575bc>] psr: 80000013
> sp : 8718bd7c ip : 00000015 fp : 7f005008
> r10: 7f005094 r9 : 893ba020 r8 : 893ba000
> r7 : 00000000 r6 : 00000001 r5 : 00000000 r4 : 00000000
> r3 : 7f15a83c r2 : 893ba020 r1 : 00000000 r0 : fffffffd
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 671d0059 DAC: 00000051
> Process insmod (pid: 730, stack limit = 0x8718a210)
> Stack: (0x8718bd7c to 0x8718c000)
> bd60: 00000000
> bd80: 00002710 870db300 c302e7e8 7f004010 893ba000 7f005094 00000000 00000000
> bda0: 00000000 00000000 00000000 00000001 00000001 00000000 014000c0 00150628
> bdc0: 7f0050ac 7f154840 1234aaaa 1234aaab c302e7e8 0000000f 00000000 893ba000
> bde0: 0000000b 7f004010 87fd54a0 ffffe000 7f157000 00000000 871b6fc0 00000001
> be00: 78e4905c 00000024 7f154640 8010179c 80a06544 8718a000 00000001 80a54980
> be20: 80a3066c 00000007 809685c0 80a54700 80a54700 07551000 80a54700 60070013
> be40: 7f154640 801f3fc8 78e4905c 7f154640 00000001 871b6fe4 7f154640 00000001
> be60: 871b6b00 00000001 78e4905c 801eaa94 00000001 871b6fe4 8718bf44 00000001
> be80: 871b6fe4 80196e4c 7f15464c 00007fff 7f154640 80193f10 87127000 7f154640
> bea0: 7f154688 80703800 7f154770 807037e4 8081b184 807bec60 807becc4 807bec6c
> bec0: 7f15481c 8010c1b8 93600000 76ed8028 00000f60 00000000 00000000 00000000
> bee0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> bf00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00003f80
> bf20: 76f5cf88 00000000 93684f80 8718a000 00160fda 00000051 00000000 801973b0
> bf40: 87671a00 93501000 00183f80 93684760 93684574 936788e0 00155000 00155290
> bf60: 00000000 00000000 00000000 00001f64 00000032 00000033 0000001d 00000000
> bf80: 00000017 00000000 00000000 00183f80 756e694c 00000080 80107684 fffffffd
> bfa0: 00000000 801074c0 00000000 00183f80 76dd9008 00183f80 00160fda 00000000
> bfc0: 00000000 00183f80 756e694c 00000080 00000001 7eabae2c 00172f8c 00000000
> bfe0: 7eabaae0 7eabaad0 0004017f 00013172 60070030 76dd9008 00000000 00000000
> [<7f1575bc>] (test_bpf_init [test_bpf]) from [<7f157000>]
> (test_bpf_init+0x0/0x1000 [test_bpf])
> [<7f157000>] (test_bpf_init [test_bpf]) from [<78e4905c>] (0x78e4905c)
> Code: e2600000 e3a01000 e58d0220 e58d1224 (e5904054)
> ---[ end trace a36398923b914fe2 ]---
> Segmentation fault
>
> Why is trying to execute TAX which is a cBPF instruction?
Kernel translates this to eBPF internally (bpf_prepare_filter() ->
bpf_migrate_filter()), no cBPF will see the JIT directly.
Is your implementation still using bpf_jit_compile() callback as
opposed to bpf_int_jit_compile()?!
Cheers,
Daniel
^ permalink raw reply [flat|nested] 67+ messages in thread