1. 15 Jul, 2022 6 commits
  2. 14 Jul, 2022 7 commits
  3. 13 Jul, 2022 4 commits
  4. 12 Jul, 2022 6 commits
  5. 11 Jul, 2022 8 commits
    • Xu Kuohai's avatar
      bpf, arm64: Add bpf trampoline for arm64 · efc9909f
      Xu Kuohai authored
      This is arm64 version of commit fec56f58 ("bpf: Introduce BPF
      trampoline"). A bpf trampoline converts native calling convention to bpf
      calling convention and is used to implement various bpf features, such
      as fentry, fexit, fmod_ret and struct_ops.
      
      This patch does essentially the same thing that bpf trampoline does on x86.
      
      Tested on Raspberry Pi 4B and qemu:
      
       #18 /1     bpf_tcp_ca/dctcp:OK
       #18 /2     bpf_tcp_ca/cubic:OK
       #18 /3     bpf_tcp_ca/invalid_license:OK
       #18 /4     bpf_tcp_ca/dctcp_fallback:OK
       #18 /5     bpf_tcp_ca/rel_setsockopt:OK
       #18        bpf_tcp_ca:OK
       #51 /1     dummy_st_ops/dummy_st_ops_attach:OK
       #51 /2     dummy_st_ops/dummy_init_ret_value:OK
       #51 /3     dummy_st_ops/dummy_init_ptr_arg:OK
       #51 /4     dummy_st_ops/dummy_multiple_args:OK
       #51        dummy_st_ops:OK
       #57 /1     fexit_bpf2bpf/target_no_callees:OK
       #57 /2     fexit_bpf2bpf/target_yes_callees:OK
       #57 /3     fexit_bpf2bpf/func_replace:OK
       #57 /4     fexit_bpf2bpf/func_replace_verify:OK
       #57 /5     fexit_bpf2bpf/func_sockmap_update:OK
       #57 /6     fexit_bpf2bpf/func_replace_return_code:OK
       #57 /7     fexit_bpf2bpf/func_map_prog_compatibility:OK
       #57 /8     fexit_bpf2bpf/func_replace_multi:OK
       #57 /9     fexit_bpf2bpf/fmod_ret_freplace:OK
       #57        fexit_bpf2bpf:OK
       #237       xdp_bpf2bpf:OK
      Signed-off-by: default avatarXu Kuohai <xukuohai@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJean-Philippe Brucker <jean-philippe@linaro.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Acked-by: default avatarKP Singh <kpsingh@kernel.org>
      Link: https://lore.kernel.org/bpf/20220711150823.2128542-5-xukuohai@huawei.com
      efc9909f
    • Xu Kuohai's avatar
      bpf, arm64: Implement bpf_arch_text_poke() for arm64 · b2ad54e1
      Xu Kuohai authored
      Implement bpf_arch_text_poke() for arm64, so bpf prog or bpf trampoline
      can be patched with it.
      
      When the target address is NULL, the original instruction is patched to
      a NOP.
      
      When the target address and the source address are within the branch
      range, the original instruction is patched to a bl instruction to the
      target address directly.
      
      To support attaching bpf trampoline to both regular kernel function and
      bpf prog, we follow the ftrace patchsite way for bpf prog. That is, two
      instructions are inserted at the beginning of bpf prog, the first one
      saves the return address to x9, and the second is a nop which will be
      patched to a bl instruction when a bpf trampoline is attached.
      
      However, when a bpf trampoline is attached to bpf prog, the distance
      between target address and source address may exceed 128MB, the maximum
      branch range, because bpf trampoline and bpf prog are allocated
      separately with vmalloc. So long jump should be handled.
      
      When a bpf prog is constructed, a plt pointing to empty trampoline
      dummy_tramp is placed at the end:
      
              bpf_prog:
                      mov x9, lr
                      nop // patchsite
                      ...
                      ret
      
              plt:
                      ldr x10, target
                      br x10
              target:
                      .quad dummy_tramp // plt target
      
      This is also the state when no trampoline is attached.
      
      When a short-jump bpf trampoline is attached, the patchsite is patched to
      a bl instruction to the trampoline directly:
      
              bpf_prog:
                      mov x9, lr
                      bl <short-jump bpf trampoline address> // patchsite
                      ...
                      ret
      
              plt:
                      ldr x10, target
                      br x10
              target:
                      .quad dummy_tramp // plt target
      
      When a long-jump bpf trampoline is attached, the plt target is filled with
      the trampoline address and the patchsite is patched to a bl instruction to
      the plt:
      
              bpf_prog:
                      mov x9, lr
                      bl plt // patchsite
                      ...
                      ret
      
              plt:
                      ldr x10, target
                      br x10
              target:
                      .quad <long-jump bpf trampoline address>
      
      dummy_tramp is used to prevent another CPU from jumping to an unknown
      location during the patching process, making the patching process easier.
      
      The patching process is as follows:
      
      1. when neither the old address or the new address is a long jump, the
         patchsite is replaced with a bl to the new address, or nop if the new
         address is NULL;
      
      2. when the old address is not long jump but the new one is, the
         branch target address is written to plt first, then the patchsite
         is replaced with a bl instruction to the plt;
      
      3. when the old address is long jump but the new one is not, the address
         of dummy_tramp is written to plt first, then the patchsite is replaced
         with a bl to the new address, or a nop if the new address is NULL;
      
      4. when both the old address and the new address are long jump, the
         new address is written to plt and the patchsite is not changed.
      Signed-off-by: default avatarXu Kuohai <xukuohai@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Reviewed-by: default avatarKP Singh <kpsingh@kernel.org>
      Reviewed-by: default avatarJean-Philippe Brucker <jean-philippe@linaro.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20220711150823.2128542-4-xukuohai@huawei.com
      b2ad54e1
    • Xu Kuohai's avatar
      arm64: Add LDR (literal) instruction · f1e8a24e
      Xu Kuohai authored
      Add LDR (literal) instruction to load data from address relative to PC.
      This instruction will be used to implement long jump from bpf prog to
      bpf trampoline in the follow-up patch.
      
      The instruction encoding:
      
          3       2   2     2                                     0        0
          0       7   6     4                                     5        0
      +-----+-------+---+-----+-------------------------------------+--------+
      | 0 x | 0 1 1 | 0 | 0 0 |                imm19                |   Rt   |
      +-----+-------+---+-----+-------------------------------------+--------+
      
      for 32-bit, variant x == 0; for 64-bit, x == 1.
      
      branch_imm_common() is used to check the distance between pc and target
      address, since it's reused by this patch and LDR (literal) is not a branch
      instruction, rename it to label_imm_common().
      Signed-off-by: default avatarXu Kuohai <xukuohai@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJean-Philippe Brucker <jean-philippe@linaro.org>
      Acked-by: default avatarWill Deacon <will@kernel.org>
      Link: https://lore.kernel.org/bpf/20220711150823.2128542-3-xukuohai@huawei.com
      f1e8a24e
    • Xu Kuohai's avatar
      bpf: Remove is_valid_bpf_tramp_flags() · 535a57a7
      Xu Kuohai authored
      Before generating bpf trampoline, x86 calls is_valid_bpf_tramp_flags()
      to check the input flags. This check is architecture independent.
      So, to be consistent with x86, arm64 should also do this check
      before generating bpf trampoline.
      
      However, the BPF_TRAMP_F_XXX flags are not used by user code and the
      flags argument is almost constant at compile time, so this run time
      check is a bit redundant.
      
      Remove is_valid_bpf_tramp_flags() and add some comments to the usage of
      BPF_TRAMP_F_XXX flags, as suggested by Alexei.
      Signed-off-by: default avatarXu Kuohai <xukuohai@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarJean-Philippe Brucker <jean-philippe@linaro.org>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20220711150823.2128542-2-xukuohai@huawei.com
      535a57a7
    • Liu Jian's avatar
      skmsg: Fix invalid last sg check in sk_msg_recvmsg() · 9974d37e
      Liu Jian authored
      In sk_psock_skb_ingress_enqueue function, if the linear area + nr_frags +
      frag_list of the SKB has NR_MSG_FRAG_IDS blocks in total, skb_to_sgvec
      will return NR_MSG_FRAG_IDS, then msg->sg.end will be set to
      NR_MSG_FRAG_IDS, and in addition, (NR_MSG_FRAG_IDS - 1) is set to the last
      SG of msg. Recv the msg in sk_msg_recvmsg, when i is (NR_MSG_FRAG_IDS - 1),
      the sk_msg_iter_var_next(i) will change i to 0 (not NR_MSG_FRAG_IDS), the
      judgment condition "msg_rx->sg.start==msg_rx->sg.end" and
      "i != msg_rx->sg.end" can not work.
      
      As a result, the processed msg cannot be deleted from ingress_msg list.
      But the length of all the sge of the msg has changed to 0. Then the next
      recvmsg syscall will process the msg repeatedly, because the length of sge
      is 0, the -EFAULT error is always returned.
      
      Fixes: 604326b4 ("bpf, sockmap: convert to generic sk_msg interface")
      Signed-off-by: default avatarLiu Jian <liujian56@huawei.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20220628123616.186950-1-liujian56@huawei.com
      9974d37e
    • Jilin Yuan's avatar
      fddi/skfp: fix repeated words in comments · edb2c347
      Jilin Yuan authored
      Delete the redundant word 'test'.
      Signed-off-by: default avatarJilin Yuan <yuanjilin@cdjrlc.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      edb2c347
    • Jilin Yuan's avatar
      ethernet/via: fix repeated words in comments · 1377a5b2
      Jilin Yuan authored
      Delete the redundant word 'driver'.
      Signed-off-by: default avatarJilin Yuan <yuanjilin@cdjrlc.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1377a5b2
    • sewookseo's avatar
      net: Find dst with sk's xfrm policy not ctl_sk · e22aa148
      sewookseo authored
      If we set XFRM security policy by calling setsockopt with option
      IPV6_XFRM_POLICY, the policy will be stored in 'sock_policy' in 'sock'
      struct. However tcp_v6_send_response doesn't look up dst_entry with the
      actual socket but looks up with tcp control socket. This may cause a
      problem that a RST packet is sent without ESP encryption & peer's TCP
      socket can't receive it.
      This patch will make the function look up dest_entry with actual socket,
      if the socket has XFRM policy(sock_policy), so that the TCP response
      packet via this function can be encrypted, & aligned on the encrypted
      TCP socket.
      
      Tested: We encountered this problem when a TCP socket which is encrypted
      in ESP transport mode encryption, receives challenge ACK at SYN_SENT
      state. After receiving challenge ACK, TCP needs to send RST to
      establish the socket at next SYN try. But the RST was not encrypted &
      peer TCP socket still remains on ESTABLISHED state.
      So we verified this with test step as below.
      [Test step]
      1. Making a TCP state mismatch between client(IDLE) & server(ESTABLISHED).
      2. Client tries a new connection on the same TCP ports(src & dst).
      3. Server will return challenge ACK instead of SYN,ACK.
      4. Client will send RST to server to clear the SOCKET.
      5. Client will retransmit SYN to server on the same TCP ports.
      [Expected result]
      The TCP connection should be established.
      
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Eric Dumazet <edumazet@google.com>
      Cc: Steffen Klassert <steffen.klassert@secunet.com>
      Cc: Sehee Lee <seheele@google.com>
      Signed-off-by: default avatarSewook Seo <sewookseo@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e22aa148
  6. 09 Jul, 2022 9 commits