netdev - Re: [PATCH bpf-next v3 2/5] bpf: Add support for setting chain call sequence for programs

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]

Date:   Tue, 08 Oct 2019 10:09:34 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Marek Majkowski <marek@...udflare.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Alan Maguire <alan.maguire@...cle.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [PATCH bpf-next v3 2/5] bpf: Add support for setting chain call sequence for programs

Daniel Borkmann <daniel@...earbox.net> writes:

> On Mon, Oct 07, 2019 at 07:20:37PM +0200, Toke Høiland-Jørgensen wrote:
>> From: Toke Høiland-Jørgensen <toke@...hat.com>
>> 
>> This adds support for setting and deleting bpf chain call programs through
>> a couple of new commands in the bpf() syscall. The CHAIN_ADD and CHAIN_DEL
>> commands take two eBPF program fds and a return code, and install the
>> 'next' program to be chain called after the 'prev' program if that program
>> returns 'retcode'. A retcode of -1 means "wildcard", so that the program
>> will be executed regardless of the previous program's return code.
>> 
>> 
>> The syscall command names are based on Alexei's prog_chain example[0],
>> which Alan helpfully rebased on current bpf-next. However, the logic and
>> program storage is obviously adapted to the execution logic in the previous
>> commit.
>> 
>> [0] https://git.kernel.org/pub/scm/linux/kernel/git/ast/bpf.git/commit/?h=prog_chain&id=f54f45d00f91e083f6aec2abe35b6f0be52ae85b&context=15
>> 
>> Signed-off-by: Alan Maguire <alan.maguire@...cle.com>
>> Signed-off-by: Toke Høiland-Jørgensen <toke@...hat.com>
>> ---
>>  include/uapi/linux/bpf.h |   10 ++++++
>>  kernel/bpf/syscall.c     |   78 ++++++++++++++++++++++++++++++++++++++++++++++
>>  2 files changed, 88 insertions(+)
>> 
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index 1ce80a227be3..b03c23963af8 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -107,6 +107,9 @@ enum bpf_cmd {
>>  	BPF_MAP_LOOKUP_AND_DELETE_ELEM,
>>  	BPF_MAP_FREEZE,
>>  	BPF_BTF_GET_NEXT_ID,
>> +	BPF_PROG_CHAIN_ADD,
>> +	BPF_PROG_CHAIN_DEL,
>> +	BPF_PROG_CHAIN_GET,
>>  };
>>  
>>  enum bpf_map_type {
>> @@ -516,6 +519,13 @@ union bpf_attr {
>>  		__u64		probe_offset;	/* output: probe_offset */
>>  		__u64		probe_addr;	/* output: probe_addr */
>>  	} task_fd_query;
>> +
>> +	struct { /* anonymous struct used by BPF_PROG_CHAIN_* commands */
>> +		__u32		prev_prog_fd;
>> +		__u32		next_prog_fd;
>> +		__u32		retcode;
>> +		__u32		next_prog_id;   /* output: prog_id */
>> +	};
>>  } __attribute__((aligned(8)));
>>  
>>  /* The description below is an attempt at providing documentation to eBPF
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index b8a203a05881..be8112e08a88 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -2113,6 +2113,79 @@ static int bpf_prog_test_run(const union bpf_attr *attr,
>>  	return ret;
>>  }
>>  
>> +#define BPF_PROG_CHAIN_LAST_FIELD next_prog_id
>> +
>> +static int bpf_prog_chain(int cmd, const union bpf_attr *attr,
>> +			  union bpf_attr __user *uattr)
>> +{
>> +	struct bpf_prog *prog, *next_prog, *old_prog;
>> +	struct bpf_prog **array;
>> +	int ret = -EOPNOTSUPP;
>> +	u32 index, prog_id;
>> +
>> +	if (CHECK_ATTR(BPF_PROG_CHAIN))
>> +		return -EINVAL;
>> +
>> +	/* Index 0 is wildcard, encoded as ~0 by userspace */
>> +	if (attr->retcode == ((u32) ~0))
>> +		index = 0;
>> +	else
>> +		index = attr->retcode + 1;
>> +
>> +	if (index >= BPF_NUM_CHAIN_SLOTS)
>> +		return -E2BIG;
>> +
>> +	prog = bpf_prog_get(attr->prev_prog_fd);
>> +	if (IS_ERR(prog))
>> +		return PTR_ERR(prog);
>> +
>> +	/* If the chain_calls bit is not set, that's because the chain call flag
>> +	 * was not set on program load, and so we can't support chain calls.
>> +	 */
>> +	if (!prog->chain_calls)
>> +		goto out;
>> +
>> +	array = prog->aux->chain_progs;
>> +
>> +	switch (cmd) {
>> +	case BPF_PROG_CHAIN_ADD:
>> +		next_prog = bpf_prog_get(attr->next_prog_fd);
>> +		if (IS_ERR(next_prog)) {
>> +			ret = PTR_ERR(next_prog);
>> +			break;
>> +		}
>> +		old_prog = xchg(array + index, next_prog);
>> +		if (old_prog)
>> +			bpf_prog_put(old_prog);
>> +		ret = 0;
>> +		break;
>
> How are circular dependencies resolved here? Seems the situation is
> not prevented, so progs unloaded via XDP won't get the __bpf_prog_free()
> call where they then drop the references of all the other progs in the
> chain.

Yeah, that's true. My plan was to just walk the "call graph" on insert
and reject any circular inserts. Just haven't gotten around to adding
that yet; will fix that in the next version.

-Toke