1. 31 3月, 2018 4 次提交
    • 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 3 次提交