linux-kernel - RE: [PATCH bpf-next 1/2] bpf, cgroup: Fix attach flags being assigned to effective progs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6305451ee5e7e_292a82086e@john.notmuch>
Date:   Tue, 23 Aug 2022 14:22:38 -0700
From:   John Fastabend <john.fastabend@...il.com>
To:     Pu Lehui <pulehui@...wei.com>, bpf@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andrii@...nel.org>,
        Quentin Monnet <quentin@...valent.com>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...nel.org>,
        Jean-Philippe Brucker <jean-philippe@...aro.org>,
        Stanislav Fomichev <sdf@...gle.com>,
        Hao Luo <haoluo@...dogle.com>, Jiri Olsa <jolsa@...nel.org>,
        Pu Lehui <pulehui@...wei.com>
Subject: RE: [PATCH bpf-next 1/2] bpf, cgroup: Fix attach flags being assigned
 to effective progs

Pu Lehui wrote:
> Attach flags is only valid for attached progs of this layer cgroup,
> but not for effective progs. We know that the attached progs is at
> the beginning of the effective progs array, so we can just populate
> the elements in front of the prog_attach_flags array.
> 
> Signed-off-by: Pu Lehui <pulehui@...wei.com>

Trying to parse above, could you add a bit more detail on why this is
problem so readers don't need to track it down.

> ---
>  kernel/bpf/cgroup.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/cgroup.c b/kernel/bpf/cgroup.c
> index 59b7eb60d5b4..9adf72e99907 100644
> --- a/kernel/bpf/cgroup.c
> +++ b/kernel/bpf/cgroup.c
> @@ -1091,11 +1091,14 @@ static int __cgroup_bpf_query(struct cgroup *cgrp, const union bpf_attr *attr,
>  		}
>  

Because we are looking at it let me try to understand. There are two
paths that set cnt relative bits here,

  if (attr->query.query_flags & BPF_F_QUERY_EFFECTIVE) {
      ...     
      cnt = min_t(int, bpf_prog_array_length(effective), total_cnt);                                       
      ...     
  } else {
     ...
     progs = &cgrp->bpf.progs[atype];
     cnt = min_t(int, prog_list_length(progs), total_cnt);
     ...
  }

And the docs claim

 *              **BPF_F_QUERY_EFFECTIVE**
 *                      Only return information regarding programs which are
 *                      currently effective at the specified *target_fd*.

so in the EFFECTIVE case should we be reporting flags at all if the
commit message says "attach flags is only valid for attached progs
of this layer cgroup, but not for effective progs."

And then in the else branch the change is what you have in the diff anyways correct?

>  		if (prog_attach_flags) {
> +			int progs_cnt = prog_list_length(&cgrp->bpf.progs[atype]);
>  			flags = cgrp->bpf.flags[atype];
>  
> -			for (i = 0; i < cnt; i++)

Do we need to min with total_cnt here so we don't walk off a short user list?

> +			/* attach flags only for attached progs, but not effective progs */
> +			for (i = 0; i < progs_cnt; i++)
>  				if (copy_to_user(prog_attach_flags + i, &flags, sizeof(flags)))
>  					return -EFAULT;
> +
>  			prog_attach_flags += cnt;
>  		}
>  
> -- 
> 2.25.1
>