You need to sign in or sign up before continuing.
  1. 03 7月, 2017 1 次提交
  2. 30 6月, 2017 1 次提交
    • D
      bpf: prevent leaking pointer via xadd on unpriviledged · 6bdf6abc
      Daniel Borkmann 提交于
      Leaking kernel addresses on unpriviledged is generally disallowed,
      for example, verifier rejects the following:
      
        0: (b7) r0 = 0
        1: (18) r2 = 0xffff897e82304400
        3: (7b) *(u64 *)(r1 +48) = r2
        R2 leaks addr into ctx
      
      Doing pointer arithmetic on them is also forbidden, so that they
      don't turn into unknown value and then get leaked out. However,
      there's xadd as a special case, where we don't check the src reg
      for being a pointer register, e.g. the following will pass:
      
        0: (b7) r0 = 0
        1: (7b) *(u64 *)(r1 +48) = r0
        2: (18) r2 = 0xffff897e82304400 ; map
        4: (db) lock *(u64 *)(r1 +48) += r2
        5: (95) exit
      
      We could store the pointer into skb->cb, loose the type context,
      and then read it out from there again to leak it eventually out
      of a map value. Or more easily in a different variant, too:
      
         0: (bf) r6 = r1
         1: (7a) *(u64 *)(r10 -8) = 0
         2: (bf) r2 = r10
         3: (07) r2 += -8
         4: (18) r1 = 0x0
         6: (85) call bpf_map_lookup_elem#1
         7: (15) if r0 == 0x0 goto pc+3
         R0=map_value(ks=8,vs=8,id=0),min_value=0,max_value=0 R6=ctx R10=fp
         8: (b7) r3 = 0
         9: (7b) *(u64 *)(r0 +0) = r3
        10: (db) lock *(u64 *)(r0 +0) += r6
        11: (b7) r0 = 0
        12: (95) exit
      
        from 7 to 11: R0=inv,min_value=0,max_value=0 R6=ctx R10=fp
        11: (b7) r0 = 0
        12: (95) exit
      
      Prevent this by checking xadd src reg for pointer types. Also
      add a couple of test cases related to this.
      
      Fixes: 1be7f75d ("bpf: enable non-root eBPF programs")
      Fixes: 17a52670 ("bpf: verifier (add verifier core)")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NEdward Cree <ecree@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6bdf6abc
  3. 21 6月, 2017 1 次提交
    • L
      selftests: Introduce tc testsuite · 76b903ee
      Lucas Bates 提交于
      Add the beginnings of a testsuite for tc functionality in the kernel.
      These are a series of unit tests that use the tc executable and verify
      the success of those commands by checking both the exit codes and the
      output from tc's 'show' operation.
      
      To run the tests:
        # cd tools/testing/selftests/tc-testing
        # sudo ./tdc.py
      
      You can specify the tc executable to use with the -p argument on the command
      line or editing the 'TC' variable in tdc_config.py. Refer to the README for
      full details on how to run.
      
      The initial complement of test cases are limited mostly to tc actions. Test
      cases are most welcome; see the creating-testcases subdirectory for help
      in creating them.
      Signed-off-by: NLucas Bates <lucasb@mojatatu.com>
      Signed-off-by: NJamal Hadi Salim <jhs@mojatatu.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      76b903ee
  4. 20 6月, 2017 1 次提交
  5. 15 6月, 2017 2 次提交
    • Y
      selftests/bpf: Add test cases to test narrower ctx field loads · 18f3d6be
      Yonghong Song 提交于
      Add test cases in test_verifier and test_progs.
      Negative tests are added in test_verifier as well.
      The test in test_progs will compare the value of narrower ctx field
      load result vs. the masked value of normal full-field load result,
      and will fail if they are not the same.
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      18f3d6be
    • Y
      bpf: permits narrower load from bpf program context fields · 31fd8581
      Yonghong Song 提交于
      Currently, verifier will reject a program if it contains an
      narrower load from the bpf context structure. For example,
              __u8 h = __sk_buff->hash, or
              __u16 p = __sk_buff->protocol
              __u32 sample_period = bpf_perf_event_data->sample_period
      which are narrower loads of 4-byte or 8-byte field.
      
      This patch solves the issue by:
        . Introduce a new parameter ctx_field_size to carry the
          field size of narrower load from prog type
          specific *__is_valid_access validator back to verifier.
        . The non-zero ctx_field_size for a memory access indicates
          (1). underlying prog type specific convert_ctx_accesses
               supporting non-whole-field access
          (2). the current insn is a narrower or whole field access.
        . In verifier, for such loads where load memory size is
          less than ctx_field_size, verifier transforms it
          to a full field load followed by proper masking.
        . Currently, __sk_buff and bpf_perf_event_data->sample_period
          are supporting narrowing loads.
        . Narrower stores are still not allowed as typical ctx stores
          are just normal stores.
      
      Because of this change, some tests in verifier will fail and
      these tests are removed. As a bonus, rename some out of bound
      __sk_buff->cb access to proper field name and remove two
      redundant "skb cb oob" tests.
      Acked-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      31fd8581
  6. 14 6月, 2017 1 次提交
  7. 11 6月, 2017 2 次提交
  8. 10 6月, 2017 2 次提交
  9. 09 6月, 2017 1 次提交
    • D
      bpf, tests: fix endianness selection · 78a5a93c
      Daniel Borkmann 提交于
      I noticed that test_l4lb was failing in selftests:
      
        # ./test_progs
        test_pkt_access:PASS:ipv4 77 nsec
        test_pkt_access:PASS:ipv6 44 nsec
        test_xdp:PASS:ipv4 2933 nsec
        test_xdp:PASS:ipv6 1500 nsec
        test_l4lb:PASS:ipv4 377 nsec
        test_l4lb:PASS:ipv6 544 nsec
        test_l4lb:FAIL:stats 6297600000 200000
        test_tcp_estats:PASS: 0 nsec
        Summary: 7 PASSED, 1 FAILED
      
      Tracking down the issue actually revealed that endianness selection
      in bpf_endian.h is broken when compiled with clang with bpf target.
      test_pkt_access.c, test_l4lb.c is compiled with __BYTE_ORDER as
      __BIG_ENDIAN, test_xdp.c as __LITTLE_ENDIAN! test_l4lb noticeably
      fails, because the test accounts bytes via bpf_ntohs(ip6h->payload_len)
      and bpf_ntohs(iph->tot_len), and compares them against a defined
      value and given a wrong endianness, the test outcome is different,
      of course.
      
      Turns out that there are actually two bugs: i) when we do __BYTE_ORDER
      comparison with __LITTLE_ENDIAN/__BIG_ENDIAN, then depending on the
      include order we see different outcomes. Reason is that __BYTE_ORDER
      is undefined due to missing endian.h include. Before we include the
      asm/byteorder.h (e.g. through linux/in.h), then __BYTE_ORDER equals
      __LITTLE_ENDIAN since both are undefined, after the include which
      correctly pulls in linux/byteorder/little_endian.h, __LITTLE_ENDIAN
      is defined, but given __BYTE_ORDER is still undefined, we match on
      __BYTE_ORDER equals to __BIG_ENDIAN since __BIG_ENDIAN is also
      undefined at that point, sigh. ii) But even that would be wrong,
      since when compiling the test cases with clang, one can select between
      bpfeb and bpfel targets for cross compilation. Hence, we can also not
      rely on what the system's endian.h provides, but we need to look at
      the compiler's defined endianness. The compiler defines __BYTE_ORDER__,
      and we can match __ORDER_LITTLE_ENDIAN__ and __ORDER_BIG_ENDIAN__,
      which also reflects targets bpf (native), bpfel, bpfeb correctly,
      thus really only rely on that. After patch:
      
        # ./test_progs
        test_pkt_access:PASS:ipv4 74 nsec
        test_pkt_access:PASS:ipv6 42 nsec
        test_xdp:PASS:ipv4 2340 nsec
        test_xdp:PASS:ipv6 1461 nsec
        test_l4lb:PASS:ipv4 400 nsec
        test_l4lb:PASS:ipv6 530 nsec
        test_tcp_estats:PASS: 0 nsec
        Summary: 7 PASSED, 0 FAILED
      
      Fixes: 43bcf707 ("bpf: fix _htons occurences in test_progs")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      78a5a93c
  10. 07 6月, 2017 1 次提交
  11. 27 5月, 2017 1 次提交
  12. 26 5月, 2017 1 次提交
  13. 19 5月, 2017 1 次提交
    • M
      selftests/powerpc: Fix TM resched DSCR test with some compilers · fe06fe86
      Michael Ellerman 提交于
      The tm-resched-dscr test has started failing sometimes, depending on
      what compiler it's built with, eg:
      
        test: tm_resched_dscr
        Check DSCR TM context switch: tm-resched-dscr: tm-resched-dscr.c:76: test_body: Assertion `rv' failed.
        !! child died by signal 6
      
      When it fails we see that the compiler doesn't initialise rv to 1 before
      entering the inline asm block. Although that's counter intuitive, it
      is allowed because we tell the compiler that the inline asm will write
      to rv (using "=r"), meaning the original value is irrelevant.
      
      Marking it as a read/write parameter would presumably work, but it seems
      simpler to fix it by setting the initial value of rv in the inline asm.
      
      Fixes: 96d01610 ("powerpc: Correct DSCR during TM context switch")
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: NMichael Neuling <mikey@neuling.org>
      fe06fe86
  14. 18 5月, 2017 3 次提交
  15. 16 5月, 2017 1 次提交
  16. 12 5月, 2017 4 次提交
  17. 09 5月, 2017 1 次提交
  18. 04 5月, 2017 2 次提交
  19. 03 5月, 2017 3 次提交
  20. 02 5月, 2017 3 次提交
  21. 01 5月, 2017 1 次提交
  22. 29 4月, 2017 3 次提交
  23. 27 4月, 2017 3 次提交