1. 31 3月, 2018 5 次提交
    • A
      libbpf: Support expected_attach_type at prog load · d7be143b
      Andrey Ignatov 提交于
      Support setting `expected_attach_type` at prog load time in both
      `bpf/bpf.h` and `bpf/libbpf.h`.
      
      Since both headers already have API to load programs, new functions are
      added not to break backward compatibility for existing ones:
      * `bpf_load_program_xattr()` is added to `bpf/bpf.h`;
      * `bpf_prog_load_xattr()` is added to `bpf/libbpf.h`.
      
      Both new functions accept structures, `struct bpf_load_program_attr` and
      `struct bpf_prog_load_attr` correspondingly, where new fields can be
      added in the future w/o changing the API.
      
      Standard `_xattr` suffix is used to name the new API functions.
      
      Since `bpf_load_program_name()` is not used as heavily as
      `bpf_load_program()`, it was removed in favor of more generic
      `bpf_load_program_xattr()`.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      d7be143b
    • A
      bpf: Check attach type at prog load time · 5e43f899
      Andrey Ignatov 提交于
      == The problem ==
      
      There are use-cases when a program of some type can be attached to
      multiple attach points and those attach points must have different
      permissions to access context or to call helpers.
      
      E.g. context structure may have fields for both IPv4 and IPv6 but it
      doesn't make sense to read from / write to IPv6 field when attach point
      is somewhere in IPv4 stack.
      
      Same applies to BPF-helpers: it may make sense to call some helper from
      some attach point, but not from other for same prog type.
      
      == The solution ==
      
      Introduce `expected_attach_type` field in in `struct bpf_attr` for
      `BPF_PROG_LOAD` command. If scenario described in "The problem" section
      is the case for some prog type, the field will be checked twice:
      
      1) At load time prog type is checked to see if attach type for it must
         be known to validate program permissions correctly. Prog will be
         rejected with EINVAL if it's the case and `expected_attach_type` is
         not specified or has invalid value.
      
      2) At attach time `attach_type` is compared with `expected_attach_type`,
         if prog type requires to have one, and, if they differ, attach will
         be rejected with EINVAL.
      
      The `expected_attach_type` is now available as part of `struct bpf_prog`
      in both `bpf_verifier_ops->is_valid_access()` and
      `bpf_verifier_ops->get_func_proto()` () and can be used to check context
      accesses and calls to helpers correspondingly.
      
      Initially the idea was discussed by Alexei Starovoitov <ast@fb.com> and
      Daniel Borkmann <daniel@iogearbox.net> here:
      https://marc.info/?l=linux-netdev&m=152107378717201&w=2Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      5e43f899
    • D
      Merge branch 'bpf-sockmap-sg-api-fixes' · 807ae7da
      Daniel Borkmann 提交于
      Prashant Bhole says:
      
      ====================
      These patches fix sg api usage in sockmap. Previously sockmap didn't
      use sg_init_table(), which caused hitting BUG_ON in sg api, when
      CONFIG_DEBUG_SG is enabled
      
      v1: added sg_init_table() calls wherever needed.
      
      v2:
      - Patch1 adds new helper function in sg api. sg_init_marker()
      - Patch2 sg_init_marker() and sg_init_table() in appropriate places
      
      Backgroud:
      While reviewing v1, John Fastabend raised a valid point about
      unnecessary memset in sg_init_table() because sockmap uses sg table
      which embedded in a struct. As enclosing struct is zeroed out, there
      is unnecessary memset in sg_init_table.
      
      So Daniel Borkmann suggested to define another static inline function
      in scatterlist.h which only initializes sg_magic. Also this function
      will be called from sg_init_table. From this suggestion I defined a
      function sg_init_marker() which sets sg_magic and calls sg_mark_end()
      ====================
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      807ae7da
    • P
      bpf: sockmap: initialize sg table entries properly · 6ef6d84c
      Prashant Bhole 提交于
      When CONFIG_DEBUG_SG is set, sg->sg_magic is initialized in
      sg_init_table() and it is verified in sg api while navigating. We hit
      BUG_ON when magic check is failed.
      
      In functions sg_tcp_sendpage and sg_tcp_sendmsg, the struct containing
      the scatterlist is already zeroed out. So to avoid extra memset, we
      use sg_init_marker() to initialize sg_magic.
      
      Fixed following things:
      - In bpf_tcp_sendpage: initialize sg using sg_init_marker
      - In bpf_tcp_sendmsg: Replace sg_init_table with sg_init_marker
      - In bpf_tcp_push: Replace memset with sg_init_table where consumed
        sg entry needs to be re-initialized.
      Signed-off-by: NPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      6ef6d84c
    • P
      lib/scatterlist: add sg_init_marker() helper · f3851786
      Prashant Bhole 提交于
      sg_init_marker initializes sg_magic in the sg table and calls
      sg_mark_end() on the last entry of the table. This can be useful to
      avoid memset in sg_init_table() when scatterlist is already zeroed out
      
      For example: when scatterlist is embedded inside other struct and that
      container struct is zeroed out
      Suggested-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Acked-by: NJohn Fastabend <john.fastabend@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      f3851786
  2. 30 3月, 2018 5 次提交
  3. 29 3月, 2018 26 次提交
  4. 28 3月, 2018 2 次提交
  5. 26 3月, 2018 2 次提交
    • D
      Merge branch 'bpf-verifier-log-btf-prep' · 2abb5fad
      Daniel Borkmann 提交于
      Martin KaFai Lau says:
      
      ====================
      This patch set has some changes and clean-up works for
      the bpf_verifier_log.  They are the prep works for the
      BTF (BPF Type Format).
      ====================
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      2abb5fad
    • M
      bpf: Add bpf_verifier_vlog() and bpf_verifier_log_needed() · 77d2e05a
      Martin KaFai Lau 提交于
      The BTF (BPF Type Format) verifier needs to reuse the current
      BPF verifier log.  Hence, it requires the following changes:
      
      (1) Expose log_write() in verifier.c for other users.
          Its name is renamed to bpf_verifier_vlog().
      
      (2) The BTF verifier also needs to check
      'log->level && log->ubuf && !bpf_verifier_log_full(log);'
      independently outside of the current log_write().  It is
      because the BTF verifier will do one-check before
      making multiple calls to btf_verifier_vlog to log
      the details of a type.
      
      Hence, this check is also re-factored to a new function
      bpf_verifier_log_needed().  Since it is re-factored,
      we can check it before va_start() in the current
      bpf_verifier_log_write() and verbose().
      Signed-off-by: NMartin KaFai Lau <kafai@fb.com>
      Acked-by: NAlexei Starovoitov <ast@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      77d2e05a