1. 26 Aug, 2020 3 commits
    • Udip Pant's avatar
      bpf: verifier: Use target program's type for access verifications · 7e40781c
      Udip Pant authored
      This patch adds changes in verifier to make decisions such as granting
      of read / write access or enforcement of return code status based on
      the program type of the target program while using dynamic program
      extension (of type BPF_PROG_TYPE_EXT).
      
      The BPF_PROG_TYPE_EXT type can be used to extend types such as XDP, SKB
      and others. Since the BPF_PROG_TYPE_EXT program type on itself is just a
      placeholder for those, we need this extended check for those extended
      programs to actually work with proper access, while using this option.
      
      Specifically, it introduces following changes:
      - may_access_direct_pkt_data:
          allow access to packet data based on the target prog
      - check_return_code:
          enforce return code based on the target prog
          (currently, this check is skipped for EXT program)
      - check_ld_abs:
          check for 'may_access_skb' based on the target prog
      - check_map_prog_compatibility:
          enforce the map compatibility check based on the target prog
      - may_update_sockmap:
          allow sockmap update based on the target prog
      
      Some other occurrences of prog->type is left as it without replacing
      with the 'resolved' type:
      - do_check_common() and check_attach_btf_id():
          already have specific logic to handle the EXT prog type
      - jit_subprogs() and bpf_check():
          Not changed for jit compilation or while inferring env->ops
      
      Next few patches in this series include selftests for some of these cases.
      Signed-off-by: default avatarUdip Pant <udippant@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200825232003.2877030-2-udippant@fb.com
      7e40781c
    • Colin Ian King's avatar
      selftests/bpf: Fix spelling mistake "scoket" -> "socket" · 7100ff7c
      Colin Ian King authored
      There is a spelling mistake in a check error message. Fix it.
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200826085907.43095-1-colin.king@canonical.com
      7100ff7c
    • Jiri Olsa's avatar
      selftests/bpf: Fix open call in trigger_fstat_events · d8397176
      Jiri Olsa authored
      Alexei reported compile breakage on newer systems with
      following error:
      
        In file included from /usr/include/fcntl.h:290:0,
        4814                 from ./test_progs.h:29,
        4815                 from
        .../bpf-next/tools/testing/selftests/bpf/prog_tests/d_path.c:3:
        4816In function ‘open’,
        4817    inlined from ‘trigger_fstat_events’ at
        .../bpf-next/tools/testing/selftests/bpf/prog_tests/d_path.c:50:10,
        4818    inlined from ‘test_d_path’ at
        .../bpf-next/tools/testing/selftests/bpf/prog_tests/d_path.c:119:6:
        4819/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
        ‘__open_missing_mode’ declared with attribute error: open with O_CREAT
        or O_TMPFILE in second argument needs 3 arguments
        4820    __open_missing_mode ();
        4821    ^~~~~~~~~~~~~~~~~~~~~~
      
      We're missing permission bits as 3rd argument
      for open call with O_CREAT flag specified.
      
      Fixes: e4d1af4b ("selftests/bpf: Add test for d_path helper")
      Reported-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200826101845.747617-1-jolsa@kernel.org
      d8397176
  2. 25 Aug, 2020 26 commits
  3. 24 Aug, 2020 11 commits
    • Lorenz Bauer's avatar
      selftests: bpf: Fix sockmap update nits · 8c3b3d97
      Lorenz Bauer authored
      Address review by Yonghong, to bring the new tests in line with the
      usual code style.
      Signed-off-by: default avatarLorenz Bauer <lmb@cloudflare.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200824084523.13104-1-lmb@cloudflare.com
      8c3b3d97
    • Andrii Nakryiko's avatar
      libbpf: Fix type compatibility check copy-paste error · f872e4bc
      Andrii Nakryiko authored
      Fix copy-paste error in types compatibility check. Local type is accidentally
      used instead of target type for the very first type check strictness check.
      This can result in potentially less strict candidate comparison. Fix the
      error.
      
      Fixes: 3fc32f40 ("libbpf: Implement type-based CO-RE relocations support")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200821225653.2180782-1-andriin@fb.com
      f872e4bc
    • Andrii Nakryiko's avatar
      libbpf: Avoid false unuinitialized variable warning in bpf_core_apply_relo · 3418c56d
      Andrii Nakryiko authored
      Some versions of GCC report uninitialized targ_spec usage. GCC is wrong, but
      let's avoid unnecessary warnings.
      
      Fixes: ddc7c304 ("libbpf: implement BPF CO-RE offset relocation algorithm")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200821225556.2178419-1-andriin@fb.com
      3418c56d
    • Jakub Sitnicki's avatar
      bpf: sk_lookup: Add user documentation · 07ff4f01
      Jakub Sitnicki authored
      Describe the purpose of BPF sk_lookup program, how it can be attached, when
      it gets invoked, and what information gets passed to it. Point the reader
      to examples and further documentation.
      Signed-off-by: default avatarJakub Sitnicki <jakub@cloudflare.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200821100226.403844-1-jakub@cloudflare.com
      07ff4f01
    • Jianlin Lv's avatar
      docs: Correct subject prefix and update LLVM info · 4d0d1673
      Jianlin Lv authored
      bpf_devel_QA.rst:152 The subject prefix information is not accurate, it
      should be 'PATCH bpf-next v2'
      
      Also update LLVM version info and add information about
      ‘-DLLVM_TARGETS_TO_BUILD’ to prompt the developer to build the desired
      target.
      Signed-off-by: default avatarJianlin Lv <Jianlin.Lv@arm.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200821052817.46887-1-Jianlin.Lv@arm.com
      4d0d1673
    • Alexei Starovoitov's avatar
      Merge branch 'bpf-tcp-header-opts' · 890f4365
      Alexei Starovoitov authored
      Martin KaFai Lau says:
      
      ====================
      The earlier effort in BPF-TCP-CC allows the TCP Congestion Control
      algorithm to be written in BPF.  It opens up opportunities to allow
      a faster turnaround time in testing/releasing new congestion control
      ideas to production environment.
      
      The same flexibility can be extended to writing TCP header option.
      It is not uncommon that people want to test new TCP header option
      to improve the TCP performance.  Another use case is for data-center
      that has a more controlled environment and has more flexibility in
      putting header options for internal traffic only.
      
      This patch set introduces the necessary BPF logic and API to
      allow bpf program to write and parse header options.
      
      There are also some changes to TCP and they are mostly to provide
      the needed sk and skb info to the bpf program to make decision.
      
      Patch 9 is the main patch and has more details on the API and design.
      
      The set includes an example which sends the max delay ack in
      the BPF TCP header option and the receiving side can
      then adjust its RTO accordingly.
      
      v5:
      - Move some of the comments from git commit message to the UAPI bpf.h
        in patch 9
      
      - Some variable clean up in the tests (patch 11).
      
      v4:
      - Since bpf-next is currently closed, tag the set with RFC to keep the
        review cadence
      
      - Separate tcp changes in its own patches (5, 6, 7).  It is a bit
        tricky since most of the tcp changes is to call out the bpf prog to
        write and parse the header.  The write and parse callout has been
        modularized into a few bpf_skops_* function in v3.
      
        This revision (v4) tries to move those bpf_skops_* functions into separate
        TCP patches.  However, they will be half implemented to highlight
        the changes to the TCP stack, mainly:
          - when the bpf prog will be called in the TCP stack and
          - what information needs to pump through the TCP stack to the actual bpf
            prog callsite.
      
        The bpf_skops_* functions will be fully implemented in patch 9 together
        with other bpf pieces.
      
      - Use struct_size() in patch 1 (Eric)
      
      - Add saw_unknown to struct tcp_options_received in patch 4 (Eric)
      
      v3:
      - Add kdoc for tcp_make_synack (Jakub Kicinski)
      - Add BPF_WRITE_HDR_TCP_CURRENT_MSS and BPF_WRITE_HDR_TCP_SYNACK_COOKIE
        in bpf.h to give a clearer meaning to sock_ops->args[0] when
        writing header option.
      - Rename BPF_SOCK_OPS_PARSE_UNKWN_HDR_OPT_CB_FLAG
        to     BPF_SOCK_OPS_PARSE_UNKNOWN_HDR_OPT_CB_FLAG
      
      v2:
      - Instead of limiting the bpf prog to write experimental
        option (kind:254, magic:0xeB9F), this revision allows the bpf prog to
        write any TCP header option through the bpf_store_hdr_opt() helper.
        That will allow different bpf-progs to write its own
        option and the helper will guarantee there is no duplication.
      
      - Add bpf_load_hdr_opt() helper to search a particular option by kind.
        Some of the get_syn logic is refactored to bpf_sock_ops_get_syn().
      
      - Since bpf prog is no longer limited to option (254, 0xeB9F),
        the TCP_SKB_CB(skb)->bpf_hdr_opt_off is no longer needed.
        Instead, when there is any option kernel cannot recognize,
        the bpf prog will be called if the
        BPF_SOCK_OPS_PARSE_UNKWN_HDR_OPT_CB_FLAG is set.
        [ The "unknown_opt" is learned in tcp_parse_options() in patch 4. ]
      
      - Add BPF_SOCK_OPS_PARSE_ALL_HDR_OPT_CB_FLAG.
        If this flag is set, the bpf-prog will be called
        on all tcp packet received at an established sk.
        It will be useful to ensure a previously written header option is
        received by the peer.
        e.g. The latter test is using this on the active-side during syncookie.
      
      - The test_tcp_hdr_options.c is adjusted accordingly
        to test writing both experimental and regular TCP header option.
      
      - The test_misc_tcp_hdr_options.c is added to mainly
        test different cases on the new helpers.
      
      - Break up the TCP_BPF_RTO_MIN and TCP_BPF_DELACK_MAX into
        two patches.
      
      - Directly store the tcp_hdrlen in "struct saved_syn" instead of
        going back to the tcp header to obtain it by "th->doff * 4"
      
      - Add a new optval(==2) for setsockopt(TCP_SAVE_SYN) such
        that it will also store the mac header (patch 9).
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      890f4365
    • Martin KaFai Lau's avatar
      tcp: bpf: Optionally store mac header in TCP_SAVE_SYN · 267cf9fa
      Martin KaFai Lau authored
      This patch is adapted from Eric's patch in an earlier discussion [1].
      
      The TCP_SAVE_SYN currently only stores the network header and
      tcp header.  This patch allows it to optionally store
      the mac header also if the setsockopt's optval is 2.
      
      It requires one more bit for the "save_syn" bit field in tcp_sock.
      This patch achieves this by moving the syn_smc bit next to the is_mptcp.
      The syn_smc is currently used with the TCP experimental option.  Since
      syn_smc is only used when CONFIG_SMC is enabled, this patch also puts
      the "IS_ENABLED(CONFIG_SMC)" around it like the is_mptcp did
      with "IS_ENABLED(CONFIG_MPTCP)".
      
      The mac_hdrlen is also stored in the "struct saved_syn"
      to allow a quick offset from the bpf prog if it chooses to start
      getting from the network header or the tcp header.
      
      [1]: https://lore.kernel.org/netdev/CANn89iLJNWh6bkH7DNhy_kmcAexuUCccqERqe7z2QsvPhGrYPQ@mail.gmail.com/Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Link: https://lore.kernel.org/bpf/20200820190123.2886935-1-kafai@fb.com
      267cf9fa
    • Martin KaFai Lau's avatar
      bpf: selftests: Tcp header options · ad2f8eb0
      Martin KaFai Lau authored
      This patch adds tests for the new bpf tcp header option feature.
      
      test_tcp_hdr_options.c:
      - It tests header option writing and parsing in 3WHS: regular
        connection establishment, fastopen, and syncookie.
      - In syncookie, the passive side's bpf prog is asking the active side
        to resend its bpf header option by specifying a RESEND bit in the
        outgoing SYNACK. handle_active_estab() and write_nodata_opt() has
        some details.
      - handle_passive_estab() has comments on fastopen.
      - It also has test for header writing and parsing in FIN packet.
      - Most of the tests is writing an experimental option 254 with magic 0xeB9F.
      - The no_exprm_estab() also tests writing a regular TCP option
        without any magic.
      
      test_misc_tcp_options.c:
      - It is an one directional test.  Active side writes option and
        passive side parses option.  The focus is to exercise
        the new helpers and API.
      - Testing the new helper: bpf_load_hdr_opt() and bpf_store_hdr_opt().
      - Testing the bpf_getsockopt(TCP_BPF_SYN).
      - Negative tests for the above helpers.
      - Testing the sock_ops->skb_data.
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200820190117.2886749-1-kafai@fb.com
      ad2f8eb0
    • Martin KaFai Lau's avatar
      bpf: selftests: Add fastopen_connect to network_helpers · 8085e1dc
      Martin KaFai Lau authored
      This patch adds a fastopen_connect() helper which will
      be used in a later test.
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200820190111.2886196-1-kafai@fb.com
      8085e1dc
    • Martin KaFai Lau's avatar
      bpf: tcp: Allow bpf prog to write and parse TCP header option · 0813a841
      Martin KaFai Lau authored
      [ Note: The TCP changes here is mainly to implement the bpf
        pieces into the bpf_skops_*() functions introduced
        in the earlier patches. ]
      
      The earlier effort in BPF-TCP-CC allows the TCP Congestion Control
      algorithm to be written in BPF.  It opens up opportunities to allow
      a faster turnaround time in testing/releasing new congestion control
      ideas to production environment.
      
      The same flexibility can be extended to writing TCP header option.
      It is not uncommon that people want to test new TCP header option
      to improve the TCP performance.  Another use case is for data-center
      that has a more controlled environment and has more flexibility in
      putting header options for internal only use.
      
      For example, we want to test the idea in putting maximum delay
      ACK in TCP header option which is similar to a draft RFC proposal [1].
      
      This patch introduces the necessary BPF API and use them in the
      TCP stack to allow BPF_PROG_TYPE_SOCK_OPS program to parse
      and write TCP header options.  It currently supports most of
      the TCP packet except RST.
      
      Supported TCP header option:
      ───────────────────────────
      This patch allows the bpf-prog to write any option kind.
      Different bpf-progs can write its own option by calling the new helper
      bpf_store_hdr_opt().  The helper will ensure there is no duplicated
      option in the header.
      
      By allowing bpf-prog to write any option kind, this gives a lot of
      flexibility to the bpf-prog.  Different bpf-prog can write its
      own option kind.  It could also allow the bpf-prog to support a
      recently standardized option on an older kernel.
      
      Sockops Callback Flags:
      ──────────────────────
      The bpf program will only be called to parse/write tcp header option
      if the following newly added callback flags are enabled
      in tp->bpf_sock_ops_cb_flags:
      BPF_SOCK_OPS_PARSE_UNKNOWN_HDR_OPT_CB_FLAG
      BPF_SOCK_OPS_PARSE_ALL_HDR_OPT_CB_FLAG
      BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG
      
      A few words on the PARSE CB flags.  When the above PARSE CB flags are
      turned on, the bpf-prog will be called on packets received
      at a sk that has at least reached the ESTABLISHED state.
      The parsing of the SYN-SYNACK-ACK will be discussed in the
      "3 Way HandShake" section.
      
      The default is off for all of the above new CB flags, i.e. the bpf prog
      will not be called to parse or write bpf hdr option.  There are
      details comment on these new cb flags in the UAPI bpf.h.
      
      sock_ops->skb_data and bpf_load_hdr_opt()
      ─────────────────────────────────────────
      sock_ops->skb_data and sock_ops->skb_data_end covers the whole
      TCP header and its options.  They are read only.
      
      The new bpf_load_hdr_opt() helps to read a particular option "kind"
      from the skb_data.
      
      Please refer to the comment in UAPI bpf.h.  It has details
      on what skb_data contains under different sock_ops->op.
      
      3 Way HandShake
      ───────────────
      The bpf-prog can learn if it is sending SYN or SYNACK by reading the
      sock_ops->skb_tcp_flags.
      
      * Passive side
      
      When writing SYNACK (i.e. sock_ops->op == BPF_SOCK_OPS_WRITE_HDR_OPT_CB),
      the received SYN skb will be available to the bpf prog.  The bpf prog can
      use the SYN skb (which may carry the header option sent from the remote bpf
      prog) to decide what bpf header option should be written to the outgoing
      SYNACK skb.  The SYN packet can be obtained by getsockopt(TCP_BPF_SYN*).
      More on this later.  Also, the bpf prog can learn if it is in syncookie
      mode (by checking sock_ops->args[0] == BPF_WRITE_HDR_TCP_SYNACK_COOKIE).
      
      The bpf prog can store the received SYN pkt by using the existing
      bpf_setsockopt(TCP_SAVE_SYN).  The example in a later patch does it.
      [ Note that the fullsock here is a listen sk, bpf_sk_storage
        is not very useful here since the listen sk will be shared
        by many concurrent connection requests.
      
        Extending bpf_sk_storage support to request_sock will add weight
        to the minisock and it is not necessary better than storing the
        whole ~100 bytes SYN pkt. ]
      
      When the connection is established, the bpf prog will be called
      in the existing PASSIVE_ESTABLISHED_CB callback.  At that time,
      the bpf prog can get the header option from the saved syn and
      then apply the needed operation to the newly established socket.
      The later patch will use the max delay ack specified in the SYN
      header and set the RTO of this newly established connection
      as an example.
      
      The received ACK (that concludes the 3WHS) will also be available to
      the bpf prog during PASSIVE_ESTABLISHED_CB through the sock_ops->skb_data.
      It could be useful in syncookie scenario.  More on this later.
      
      There is an existing getsockopt "TCP_SAVED_SYN" to return the whole
      saved syn pkt which includes the IP[46] header and the TCP header.
      A few "TCP_BPF_SYN*" getsockopt has been added to allow specifying where to
      start getting from, e.g. starting from TCP header, or from IP[46] header.
      
      The new getsockopt(TCP_BPF_SYN*) will also know where it can get
      the SYN's packet from:
        - (a) the just received syn (available when the bpf prog is writing SYNACK)
              and it is the only way to get SYN during syncookie mode.
        or
        - (b) the saved syn (available in PASSIVE_ESTABLISHED_CB and also other
              existing CB).
      
      The bpf prog does not need to know where the SYN pkt is coming from.
      The getsockopt(TCP_BPF_SYN*) will hide this details.
      
      Similarly, a flags "BPF_LOAD_HDR_OPT_TCP_SYN" is also added to
      bpf_load_hdr_opt() to read a particular header option from the SYN packet.
      
      * Fastopen
      
      Fastopen should work the same as the regular non fastopen case.
      This is a test in a later patch.
      
      * Syncookie
      
      For syncookie, the later example patch asks the active
      side's bpf prog to resend the header options in ACK.  The server
      can use bpf_load_hdr_opt() to look at the options in this
      received ACK during PASSIVE_ESTABLISHED_CB.
      
      * Active side
      
      The bpf prog will get a chance to write the bpf header option
      in the SYN packet during WRITE_HDR_OPT_CB.  The received SYNACK
      pkt will also be available to the bpf prog during the existing
      ACTIVE_ESTABLISHED_CB callback through the sock_ops->skb_data
      and bpf_load_hdr_opt().
      
      * Turn off header CB flags after 3WHS
      
      If the bpf prog does not need to write/parse header options
      beyond the 3WHS, the bpf prog can clear the bpf_sock_ops_cb_flags
      to avoid being called for header options.
      Or the bpf-prog can select to leave the UNKNOWN_HDR_OPT_CB_FLAG on
      so that the kernel will only call it when there is option that
      the kernel cannot handle.
      
      [1]: draft-wang-tcpm-low-latency-opt-00
           https://tools.ietf.org/html/draft-wang-tcpm-low-latency-opt-00Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200820190104.2885895-1-kafai@fb.com
      0813a841
    • Martin KaFai Lau's avatar
      bpf: sock_ops: Change some members of sock_ops_kern from u32 to u8 · c9985d09
      Martin KaFai Lau authored
      A later patch needs to add a few pointers and a few u8 to
      sock_ops_kern.  Hence, this patch saves some spaces by moving
      some of the existing members from u32 to u8 so that the later
      patch can still fit everything in a cacheline.
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20200820190058.2885640-1-kafai@fb.com
      c9985d09