1. 24 Aug, 2020 11 commits
    • 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
    • Martin KaFai Lau's avatar
      bpf: tcp: Add bpf_skops_hdr_opt_len() and bpf_skops_write_hdr_opt() · 331fca43
      Martin KaFai Lau authored
      The bpf prog needs to parse the SYN header to learn what options have
      been sent by the peer's bpf-prog before writing its options into SYNACK.
      This patch adds a "syn_skb" arg to tcp_make_synack() and send_synack().
      This syn_skb will eventually be made available (as read-only) to the
      bpf prog.  This will be the only SYN packet available to the bpf
      prog during syncookie.  For other regular cases, the bpf prog can
      also use the saved_syn.
      
      When writing options, the bpf prog will first be called to tell the
      kernel its required number of bytes.  It is done by the new
      bpf_skops_hdr_opt_len().  The bpf prog will only be called when the new
      BPF_SOCK_OPS_WRITE_HDR_OPT_CB_FLAG is set in tp->bpf_sock_ops_cb_flags.
      When the bpf prog returns, the kernel will know how many bytes are needed
      and then update the "*remaining" arg accordingly.  4 byte alignment will
      be included in the "*remaining" before this function returns.  The 4 byte
      aligned number of bytes will also be stored into the opts->bpf_opt_len.
      "bpf_opt_len" is a newly added member to the struct tcp_out_options.
      
      Then the new bpf_skops_write_hdr_opt() will call the bpf prog to write the
      header options.  The bpf prog is only called if it has reserved spaces
      before (opts->bpf_opt_len > 0).
      
      The bpf prog is the last one getting a chance to reserve header space
      and writing the header option.
      
      These two functions are half implemented to highlight the changes in
      TCP stack.  The actual codes preparing the bpf running context and
      invoking the bpf prog will be added in the later patch with other
      necessary bpf pieces.
      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/20200820190052.2885316-1-kafai@fb.com
      331fca43
    • Martin KaFai Lau's avatar
      bpf: tcp: Add bpf_skops_parse_hdr() · 00d211a4
      Martin KaFai Lau authored
      The patch adds a function bpf_skops_parse_hdr().
      It will call the bpf prog to parse the TCP header received at
      a tcp_sock that has at least reached the ESTABLISHED state.
      
      For the packets received during the 3WHS (SYN, SYNACK and ACK),
      the received skb will be available to the bpf prog during the callback
      in bpf_skops_established() introduced in the previous patch and
      in the bpf_skops_write_hdr_opt() that will be added in the
      next patch.
      
      Calling bpf prog to parse header is controlled by two new flags in
      tp->bpf_sock_ops_cb_flags:
      BPF_SOCK_OPS_PARSE_UNKNOWN_HDR_OPT_CB_FLAG and
      BPF_SOCK_OPS_PARSE_ALL_HDR_OPT_CB_FLAG.
      
      When BPF_SOCK_OPS_PARSE_UNKNOWN_HDR_OPT_CB_FLAG is set,
      the bpf prog will only be called when there is unknown
      option in the TCP header.
      
      When BPF_SOCK_OPS_PARSE_ALL_HDR_OPT_CB_FLAG is set,
      the bpf prog will be called on all received TCP header.
      
      This function is half implemented to highlight the changes in
      TCP stack.  The actual codes preparing the bpf running context and
      invoking the bpf prog will be added in the later patch with other
      necessary bpf pieces.
      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/20200820190046.2885054-1-kafai@fb.com
      00d211a4
    • Martin KaFai Lau's avatar
      bpf: tcp: Add bpf_skops_established() · 72be0fe6
      Martin KaFai Lau authored
      In tcp_init_transfer(), it currently calls the bpf prog to give it a
      chance to handle the just "ESTABLISHED" event (e.g. do setsockopt
      on the newly established sk).  Right now, it is done by calling the
      general purpose tcp_call_bpf().
      
      In the later patch, it also needs to pass the just-received skb which
      concludes the 3 way handshake. E.g. the SYNACK received at the active side.
      The bpf prog can then learn some specific header options written by the
      peer's bpf-prog and potentially do setsockopt on the newly established sk.
      Thus, instead of reusing the general purpose tcp_call_bpf(), a new function
      bpf_skops_established() is added to allow passing the "skb" to the bpf
      prog.  The actual skb passing from bpf_skops_established() to the bpf prog
      will happen together in a later patch which has the necessary bpf pieces.
      
      A "skb" arg is also added to tcp_init_transfer() such that
      it can then be passed to bpf_skops_established().
      
      Calling the new bpf_skops_established() instead of tcp_call_bpf()
      should be a noop in this patch.
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200820190039.2884750-1-kafai@fb.com
      72be0fe6
    • Martin KaFai Lau's avatar
      tcp: Add saw_unknown to struct tcp_options_received · 7656d684
      Martin KaFai Lau authored
      In a later patch, the bpf prog only wants to be called to handle
      a header option if that particular header option cannot be handled by
      the kernel.  This unknown option could be written by the peer's bpf-prog.
      It could also be a new standard option that the running kernel does not
      support it while a bpf-prog can handle it.
      
      This patch adds a "saw_unknown" bit to "struct tcp_options_received"
      and it uses an existing one byte hole to do that.  "saw_unknown" will
      be set in tcp_parse_options() if it sees an option that the kernel
      cannot handle.
      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>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200820190033.2884430-1-kafai@fb.com
      7656d684
    • Martin KaFai Lau's avatar
      tcp: bpf: Add TCP_BPF_RTO_MIN for bpf_setsockopt · ca584ba0
      Martin KaFai Lau authored
      This patch adds bpf_setsockopt(TCP_BPF_RTO_MIN) to allow bpf prog
      to set the min rto of a connection.  It could be used together
      with the earlier patch which has added bpf_setsockopt(TCP_BPF_DELACK_MAX).
      
      A later selftest patch will communicate the max delay ack in a
      bpf tcp header option and then the receiving side can use
      bpf_setsockopt(TCP_BPF_RTO_MIN) to set a shorter rto.
      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>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200820190027.2884170-1-kafai@fb.com
      ca584ba0
    • Martin KaFai Lau's avatar
      tcp: bpf: Add TCP_BPF_DELACK_MAX setsockopt · 2b8ee4f0
      Martin KaFai Lau authored
      This change is mostly from an internal patch and adapts it from sysctl
      config to the bpf_setsockopt setup.
      
      The bpf_prog can set the max delay ack by using
      bpf_setsockopt(TCP_BPF_DELACK_MAX).  This max delay ack can be communicated
      to its peer through bpf header option.  The receiving peer can then use
      this max delay ack and set a potentially lower rto by using
      bpf_setsockopt(TCP_BPF_RTO_MIN) which will be introduced
      in the next patch.
      
      Another later selftest patch will also use it like the above to show
      how to write and parse bpf tcp header option.
      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>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200820190021.2884000-1-kafai@fb.com
      2b8ee4f0
    • Martin KaFai Lau's avatar
      tcp: Use a struct to represent a saved_syn · 70a217f1
      Martin KaFai Lau authored
      The TCP_SAVE_SYN has both the network header and tcp header.
      The total length of the saved syn packet is currently stored in
      the first 4 bytes (u32) of an array and the actual packet data is
      stored after that.
      
      A later patch will add a bpf helper that allows to get the tcp header
      alone from the saved syn without the network header.  It will be more
      convenient to have a direct offset to a specific header instead of
      re-parsing it.  This requires to separately store the network hdrlen.
      The total header length (i.e. network + tcp) is still needed for the
      current usage in getsockopt.  Although this total length can be obtained
      by looking into the tcphdr and then get the (th->doff << 2), this patch
      chooses to directly store the tcp hdrlen in the second four bytes of
      this newly created "struct saved_syn".  By using a new struct, it can
      give a readable name to each individual header length.
      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>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Link: https://lore.kernel.org/bpf/20200820190014.2883694-1-kafai@fb.com
      70a217f1
  2. 21 Aug, 2020 17 commits
  3. 20 Aug, 2020 10 commits
    • Andrii Nakryiko's avatar
      selftests/bpf: List newest Clang built-ins needed for some CO-RE selftests · 149cb339
      Andrii Nakryiko authored
      Record which built-ins are optional and needed for some of recent BPF CO-RE
      subtests. Document Clang diff that fixed corner-case issue with
      __builtin_btf_type_id().
      Suggested-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-4-andriin@fb.com
      149cb339
    • Andrii Nakryiko's avatar
      selftests/bpf: Fix two minor compilation warnings reported by GCC 4.9 · 37a6a9e7
      Andrii Nakryiko authored
      GCC 4.9 seems to be more strict in some regards. Fix two minor issue it
      reported.
      
      Fixes: 1c1052e0 ("tools/testing/selftests/bpf: Add self-tests for new helper bpf_get_ns_current_pid_tgid.")
      Fixes: 2d7824ff ("selftests: bpf: Add test for sk_assign")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-3-andriin@fb.com
      37a6a9e7
    • Andrii Nakryiko's avatar
      libbpf: Fix libbpf build on compilers missing __builtin_mul_overflow · dda1ec9f
      Andrii Nakryiko authored
      GCC compilers older than version 5 don't support __builtin_mul_overflow yet.
      Given GCC 4.9 is the minimal supported compiler for building kernel and the
      fact that libbpf is a dependency of resolve_btfids, which is dependency of
      CONFIG_DEBUG_INFO_BTF=y, this needs to be handled. This patch fixes the issue
      by falling back to slower detection of integer overflow in such cases.
      
      Fixes: 029258d7 ("libbpf: Remove any use of reallocarray() in libbpf")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-2-andriin@fb.com
      dda1ec9f
    • Andrii Nakryiko's avatar
      libbpf: Fix detection of BPF helper call instruction · 9b2f6fec
      Andrii Nakryiko authored
      BPF_CALL | BPF_JMP32 is explicitly not allowed by verifier for BPF helper
      calls, so don't detect it as a valid call. Also drop the check on func_id
      pointer, as it's currently always non-null.
      
      Fixes: 109cea5a ("libbpf: Sanitize BPF program code for bpf_probe_read_{kernel, user}[_str]")
      Reported-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-1-andriin@fb.com
      9b2f6fec
    • Daniel Borkmann's avatar
      Merge branch 'bpf-umd-debug' · 0bc23a1d
      Daniel Borkmann authored
      Alexei Starovoitov says:
      
      ====================
      This patch set is the first real user of user mode driver facility. The
      general use case for user mode driver is to ship vmlinux with preloaded BPF
      programs. In this particular case the user mode driver populates bpffs instance
      with two BPF iterators. In several months BPF_LSM project would need to preload
      the kernel with its own set of BPF programs and attach to LSM hooks instead of
      bpffs. BPF iterators and BPF_LSM are unstable from uapi perspective. They are
      tracing based and peek into arbitrary kernel data structures. One can question
      why a kernel module cannot embed BPF programs inside. The reason is that libbpf
      is necessary to load them. First libbpf loads BPF Type Format, then creates BPF
      maps, populates them. Then it relocates code sections inside BPF programs,
      loads BPF programs, and finally attaches them to events. Theoretically libbpf
      can be rewritten to work in the kernel, but that is massive undertaking. The
      maintenance of in-kernel libbpf and user space libbpf would be another
      challenge. Another obstacle to embedding BPF programs into kernel module is
      sys_bpf api. Loading of programs, BTF, maps goes through the verifier. It
      validates and optimizes the code. It's possible to provide in-kernel api to all
      of sys_bpf commands (load progs, create maps, update maps, load BTF, etc), but
      that is huge amount of work and forever maintenance headache.
      Hence the decision is to ship vmlinux with user mode drivers that load
      BPF programs. Just like kernel modules extend vmlinux BPF programs
      are safe extensions of the kernel and some of them need to ship with vmlinux.
      
      This patch set adds a kernel module with user mode driver that populates bpffs
      with two BPF iterators.
      
      $ mount bpffs /my/bpffs/ -t bpf
      $ ls -la /my/bpffs/
      total 4
      drwxrwxrwt  2 root root    0 Jul  2 00:27 .
      drwxr-xr-x 19 root root 4096 Jul  2 00:09 ..
      -rw-------  1 root root    0 Jul  2 00:27 maps.debug
      -rw-------  1 root root    0 Jul  2 00:27 progs.debug
      
      The user mode driver will load BPF Type Formats, create BPF maps, populate BPF
      maps, load two BPF programs, attach them to BPF iterators, and finally send two
      bpf_link IDs back to the kernel.
      The kernel will pin two bpf_links into newly mounted bpffs instance under
      names "progs.debug" and "maps.debug". These two files become human readable.
      
      $ cat /my/bpffs/progs.debug
        id name            attached
        11 dump_bpf_map    bpf_iter_bpf_map
        12 dump_bpf_prog   bpf_iter_bpf_prog
        27 test_pkt_access
        32 test_main       test_pkt_access test_pkt_access
        33 test_subprog1   test_pkt_access_subprog1 test_pkt_access
        34 test_subprog2   test_pkt_access_subprog2 test_pkt_access
        35 test_subprog3   test_pkt_access_subprog3 test_pkt_access
        36 new_get_skb_len get_skb_len test_pkt_access
        37 new_get_skb_ifindex get_skb_ifindex test_pkt_access
        38 new_get_constant get_constant test_pkt_access
      
      The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
      all BPF programs currently loaded in the system. This information is unstable
      and will change from kernel to kernel.
      
      In some sence this output is similar to 'bpftool prog show' that is using
      stable api to retreive information about BPF programs. The BPF subsytems grows
      quickly and there is always demand to show as much info about BPF things as
      possible. But we cannot expose all that info via stable uapi of bpf syscall,
      since the details change so much. Right now a BPF program can be attached to
      only one other BPF program. Folks are working on patches to enable
      multi-attach, but for debugging it's necessary to see the current state. There
      is no uapi for that, but above output shows it:
        37 new_get_skb_ifindex  get_skb_ifindex test_pkt_access
        38 new_get_constant     get_constant    test_pkt_access
           [1]                  [2]             [3]
      [1] is the full name of BPF prog from BTF.
      [2] is the name of function inside target BPF prog.
      [3] is the name of target BPF prog.
      
      [2] and [3] are not exposed via uapi, since they will change from single to
      multi soon. There are many other cases where bpf internals are useful for
      debugging, but shouldn't be exposed via uapi due to high rate of changes.
      
      systemd mounts /sys/fs/bpf at the start, so this kernel module with user mode
      driver needs to be available early. BPF_LSM most likely would need to preload
      BPF programs even earlier.
      
      Few interesting observations:
      - though bpffs comes with two human readble files "progs.debug" and
        "maps.debug" they can be removed. 'rm -f /sys/fs/bpf/progs.debug' will remove
        bpf_link and kernel will automatically unload corresponding BPF progs, maps,
        BTFs. In the future '-o remount' will be able to restore them. This is not
        implemented yet.
      
      - 'ps aux|grep bpf_preload' shows nothing. User mode driver loaded BPF
        iterators and exited. Nothing is lingering in user space at this point.
      
      - We can consider giving 0644 permissions to "progs.debug" and "maps.debug"
        to allow unprivileged users see BPF things loaded in the system.
        We cannot do so with "bpftool prog show", since it's using cap_sys_admin
        parts of bpf syscall.
      
      - The functionality split between core kernel, bpf_preload kernel module and
        user mode driver is very similar to bpfilter style of interaction.
      
      - Similar BPF iterators can be used as unstable extensions to /proc.
        Like mounting /proc can prepopolate some subdirectory in there with
        a BPF iterator that will print QUIC sockets instead of tcp and udp.
      
      Changelog:
      
      v5->v6:
      - refactored Makefiles with Andrii's help
        - switched to explicit $(MAKE) style
        - switched to userldlibs instead of userldflags
        - fixed build issue with libbpf Makefile due to invocation from kbuild
      - fixed menuconfig order as spotted by Daniel
      - introduced CONFIG_USERMODE_DRIVER bool that is selected by bpfilter and bpf_preload
      
      v4->v5:
      - addressed Song and Andrii feedback. s/pages/max_entries/
      
      v3->v4:
      - took THIS_MODULE in patch 3 as suggested by Daniel to simplify the code.
      - converted BPF iterator to use BTF (when available) to print full BPF program name
      instead of 16-byte truncated version.
      This is something I've been using drgn scripts for.
      Take a look at get_name() in iterators.bpf.c to see how short it is comparing
      to what user space bpftool would have to do to print the same full name:
      . get prog info via obj_info_by_fd
      . do get_fd_by_id from info->btf_id
      . fetch potentially large BTF of the program from the kernel
      . parse that BTF in user space to figure out all type boundaries and string section
      . read info->func_info to get btf_id of func_proto from there
      . find that btf_id in the parsed BTF
      That's quite a bit work for bpftool comparing to few lines in get_name().
      I guess would be good to make bpftool do this info extraction anyway.
      While doing this BTF reading in the kernel realized that the verifier is not smart
      enough to follow double pointers (added to my todo list), otherwise get_name()
      would have been even shorter.
      
      v2->v3:
      - fixed module unload race (Daniel)
      - added selftest (Daniel)
      - fixed build bot warning
      
      v1->v2:
      - changed names to 'progs.debug' and 'maps.debug' to hopefully better indicate
        instability of the text output. Having dot in the name also guarantees
        that these special files will not conflict with normal bpf objects pinned
        in bpffs, since dot is disallowed for normal pins.
      - instead of hard coding link_name in the core bpf moved into UMD.
      - cleanedup error handling.
      - addressed review comments from Yonghong and Andrii.
      ====================
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      0bc23a1d
    • Alexei Starovoitov's avatar
      selftests/bpf: Add bpffs preload test. · edb65ee5
      Alexei Starovoitov authored
      Add a test that mounts two bpffs instances and checks progs.debug
      and maps.debug for sanity data.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-5-alexei.starovoitov@gmail.com
      edb65ee5
    • Alexei Starovoitov's avatar
      bpf: Add kernel module with user mode driver that populates bpffs. · d71fa5c9
      Alexei Starovoitov authored
      Add kernel module with user mode driver that populates bpffs with
      BPF iterators.
      
      $ mount bpffs /my/bpffs/ -t bpf
      $ ls -la /my/bpffs/
      total 4
      drwxrwxrwt  2 root root    0 Jul  2 00:27 .
      drwxr-xr-x 19 root root 4096 Jul  2 00:09 ..
      -rw-------  1 root root    0 Jul  2 00:27 maps.debug
      -rw-------  1 root root    0 Jul  2 00:27 progs.debug
      
      The user mode driver will load BPF Type Formats, create BPF maps, populate BPF
      maps, load two BPF programs, attach them to BPF iterators, and finally send two
      bpf_link IDs back to the kernel.
      The kernel will pin two bpf_links into newly mounted bpffs instance under
      names "progs.debug" and "maps.debug". These two files become human readable.
      
      $ cat /my/bpffs/progs.debug
        id name            attached
        11 dump_bpf_map    bpf_iter_bpf_map
        12 dump_bpf_prog   bpf_iter_bpf_prog
        27 test_pkt_access
        32 test_main       test_pkt_access test_pkt_access
        33 test_subprog1   test_pkt_access_subprog1 test_pkt_access
        34 test_subprog2   test_pkt_access_subprog2 test_pkt_access
        35 test_subprog3   test_pkt_access_subprog3 test_pkt_access
        36 new_get_skb_len get_skb_len test_pkt_access
        37 new_get_skb_ifindex get_skb_ifindex test_pkt_access
        38 new_get_constant get_constant test_pkt_access
      
      The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
      all BPF programs currently loaded in the system. This information is unstable
      and will change from kernel to kernel as ".debug" suffix conveys.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-4-alexei.starovoitov@gmail.com
      d71fa5c9
    • Alexei Starovoitov's avatar
      bpf: Add BPF program and map iterators as built-in BPF programs. · f0fdfefb
      Alexei Starovoitov authored
      The program and map iterators work similar to seq_file-s.
      Once the program is pinned in bpffs it can be read with "cat" tool
      to print human readable output. In this case about BPF programs and maps.
      For example:
      $ cat /sys/fs/bpf/progs.debug
        id name            attached
         5 dump_bpf_map    bpf_iter_bpf_map
         6 dump_bpf_prog   bpf_iter_bpf_prog
      $ cat /sys/fs/bpf/maps.debug
        id name            max_entries
         3 iterator.rodata     1
      
      To avoid kernel build dependency on clang 10 separate bpf skeleton generation
      into manual "make" step and instead check-in generated .skel.h into git.
      
      Unlike 'bpftool prog show' in-kernel BTF name is used (when available)
      to print full name of BPF program instead of 16-byte truncated name.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-3-alexei.starovoitov@gmail.com
      f0fdfefb
    • Alexei Starovoitov's avatar
      bpf: Factor out bpf_link_by_id() helper. · 005142b8
      Alexei Starovoitov authored
      Refactor the code a bit to extract bpf_link_by_id() helper.
      It's similar to existing bpf_prog_by_id().
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-2-alexei.starovoitov@gmail.com
      005142b8
    • Xu Wang's avatar
  4. 19 Aug, 2020 2 commits
    • Alexei Starovoitov's avatar
      Merge branch 'type-and-enum-value-relos' · c1447efd
      Alexei Starovoitov authored
      Andrii Nakryiko says:
      
      ====================
      This patch set adds libbpf support for two new classes of CO-RE relocations:
      type-based (TYPE_EXISTS/TYPE_SIZE/TYPE_ID_LOCAL/TYPE_ID_TARGET) and enum
      value-vased (ENUMVAL_EXISTS/ENUMVAL_VALUE):
        - TYPE_EXISTS allows to detect presence in kernel BTF of a locally-recorded
          BTF type. Useful for feature detection (new functionality often comes with
          new internal kernel types), as well as handling type renames and bigger
          refactorings.
        - TYPE_SIZE allows to get the real size (in bytes) of a specified kernel
          type. Useful for dumping internal structure as-is through perfbuf or
          ringbuf.
        - TYPE_ID_LOCAL/TYPE_ID_TARGET allow to capture BTF type ID of a BTF type in
          program's BTF or kernel BTF, respectively. These could be used for
          high-performance and space-efficient generic data dumping/logging by
          relying on small and cheap BTF type ID as a data layout descriptor, for
          post-processing on user-space side.
        - ENUMVAL_EXISTS can be used for detecting the presence of enumerator value
          in kernel's enum type. Most direct application is to detect BPF helper
          support in kernel.
        - ENUMVAL_VALUE allows to relocate real integer value of kernel enumerator
          value, which is subject to change (e.g., always a potential issue for
          internal, non-UAPI, kernel enums).
      
      I've indicated potential applications for these relocations, but relocations
      themselves are generic and unassuming and are designed to work correctly even
      in unintended applications. Furthermore, relocated values become constants,
      known to the verifier and could and would be used for dead branch code
      detection and elimination. This makes them ideal to do all sorts of feature
      detection and guarding functionality that's not available on some older (but
      still supported by BPF program) kernels, while having to compile and maintain
      one unified source code.
      
      Selftests are added for all the new features. Selftests utilizing new Clang
      built-ins are designed such that they will compile with older Clangs and will
      be skipped during test runs. So this shouldn't cause any build and test
      failures on systems with slightly outdated Clang compiler.
      
      LLVM patches adding these relocation in Clang:
        - __builtin_btf_type_id() ([0], [1], [2]);
        - __builtin_preserve_type_info(), __builtin_preserve_enum_value() ([3], [4]).
      
        [0] https://reviews.llvm.org/D74572
        [1] https://reviews.llvm.org/D74668
        [2] https://reviews.llvm.org/D85174
        [3] https://reviews.llvm.org/D83878
        [4] https://reviews.llvm.org/D83242
      
      v2->v3:
        - fix feature detection for __builtin_btf_type_id() test (Yonghong);
        - fix extra empty lines at the end of files (Yonghong);
      
      v1->v2:
        - selftests detect built-in support and are skipped if not found (Alexei).
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c1447efd
    • Andrii Nakryiko's avatar
      selftests/bpf: Add tests for ENUMVAL_EXISTS/ENUMVAL_VALUE relocations · 33574905
      Andrii Nakryiko authored
      Add tests validating existence and value relocations for enum value-based
      relocations. If __builtin_preserve_enum_value() built-in is not supported,
      skip tests.
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200819194519.3375898-6-andriin@fb.com
      33574905