05 Oct, 2015

1 commit

  • For ARMv7 with UDIV instruction support, generate an UDIV instruction
    followed by an MLS instruction.

    For other ARM variants, generate code calling a C wrapper similar to
    the jit_udiv() function used for BPF_ALU | BPF_DIV instructions.

    Some performance numbers reported by the test_bpf module (the duration
    per filter run is reported in nanoseconds, between "jitted:" and
    "PASS":

    ARMv7 QEMU nojit: test_bpf: #3 DIV_MOD_KX jited:0 2196 PASS
    ARMv7 QEMU jit: test_bpf: #3 DIV_MOD_KX jited:1 104 PASS
    ARMv5 QEMU nojit: test_bpf: #3 DIV_MOD_KX jited:0 2176 PASS
    ARMv5 QEMU jit: test_bpf: #3 DIV_MOD_KX jited:1 1104 PASS
    ARMv5 kirkwood nojit: test_bpf: #3 DIV_MOD_KX jited:0 1103 PASS
    ARMv5 kirkwood jit: test_bpf: #3 DIV_MOD_KX jited:1 311 PASS

    Signed-off-by: Nicolas Schichan
    Acked-by: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Nicolas Schichan
     

28 Jul, 2015

1 commit


24 Sep, 2014

1 commit

  • Will Deacon pointed out, that the currently used opcode for filling holes,
    that is 0xe7ffffff, seems not robust enough ...

    $ echo 0xffffffe7 | xxd -r > test.bin
    $ arm-linux-gnueabihf-objdump -m arm -D -b binary test.bin
    ...
    0: e7ffffff udf #65535 ; 0xffff

    ... while for Thumb, it ends up as ...

    0: ffff e7ff vqshl.u64 q15, , #63

    ... which is a bit fragile. The ARM specification defines some *permanently*
    guaranteed undefined instruction (UDF) space, for example for ARM in ARMv7-AR,
    section A5.4 and for Thumb in ARMv7-M, section A5.2.6.

    Similarly, ptrace, kprobes, kgdb, bug and uprobes make use of such instruction
    as well to trap. Given mentioned section from the specification, we can find
    such a universe as (where 'x' denotes 'don't care'):

    ARM: xxxx 0111 1111 xxxx xxxx xxxx 1111 xxxx
    Thumb: 1101 1110 xxxx xxxx

    We therefore should use a more robust opcode that fits both. Russell King
    suggested that we can even reuse a single 32-bit word, that is, 0xe7fddef1
    which will fault if executed in ARM *or* Thumb mode as done in f928d4f2a86f
    ("ARM: poison the vectors page"). That will still hold our requirements:

    $ echo 0xf1defde7 | xxd -r > test.bin
    $ arm-unknown-linux-gnueabi-objdump -m arm -D -b binary test.bin
    ...
    0: e7fddef1 udf #56801 ; 0xdde1
    $ echo 0xf1defde7f1defde7f1defde7 | xxd -r > test.bin
    $ arm-unknown-linux-gnueabi-objdump -marm -Mforce-thumb -D -b binary test.bin
    ...
    0: def1 udf #241 ; 0xf1
    2: e7fd b.n 0x0
    4: def1 udf #241 ; 0xf1
    6: e7fd b.n 0x4
    8: def1 udf #241 ; 0xf1
    a: e7fd b.n 0x8

    So on ARM 0xe7fddef1 conforms to the above UDF pattern, and the low 16 bit
    likewise correspond to UDF in Thumb case. The 0xe7fd part is an unconditional
    branch back to the UDF instruction.

    Signed-off-by: Daniel Borkmann
    Cc: Russell King
    Cc: Catalin Marinas
    Cc: Will Deacon
    Cc: Mircea Gherzan
    Cc: Alexei Starovoitov
    Signed-off-by: David S. Miller

    Daniel Borkmann
     

14 Nov, 2012

1 commit


14 Jun, 2012

1 commit


24 Mar, 2012

1 commit

  • Based of Matt Evans's PPC64 implementation.

    The compiler generates ARM instructions but interworking is
    supported for Thumb2 kernels.

    Supports both little and big endian. Unaligned loads are emitted
    for ARMv6+. Not all the BPF opcodes that deal with ancillary data
    are supported. The scratch memory of the filter lives on the stack.
    Hardware integer division is used if it is available.

    Enabled in the same way as for x86-64 and PPC64:

    echo 1 > /proc/sys/net/core/bpf_jit_enable

    A value greater than 1 enables opcode output.

    Signed-off-by: Mircea Gherzan
    Acked-by: David S. Miller
    Acked-by: Eric Dumazet
    Signed-off-by: Russell King

    Mircea Gherzan