netdev - Re: [PATCH bpf-next v4 11/11] bpf: use a table to drive helper arg type checks

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:   Mon, 21 Sep 2020 15:23:35 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Lorenz Bauer <lmb@...udflare.com>
Cc:     ast@...nel.org, daniel@...earbox.net, bpf@...r.kernel.org,
        netdev@...r.kernel.org, Martin KaFai Lau <kafai@...com>
Subject: Re: [PATCH bpf-next v4 11/11] bpf: use a table to drive helper arg
 type checks

On Mon, Sep 21, 2020 at 01:12:27PM +0100, Lorenz Bauer wrote:
> +struct bpf_reg_types {
> +	const enum bpf_reg_type types[10];
> +};

any idea on how to make it more robust?

> +
> +static const struct bpf_reg_types *compatible_reg_types[] = {
> +	[ARG_PTR_TO_MAP_KEY]		= &map_key_value_types,
> +	[ARG_PTR_TO_MAP_VALUE]		= &map_key_value_types,
> +	[ARG_PTR_TO_UNINIT_MAP_VALUE]	= &map_key_value_types,
> +	[ARG_PTR_TO_MAP_VALUE_OR_NULL]	= &map_key_value_types,
> +	[ARG_CONST_SIZE]		= &scalar_types,
> +	[ARG_CONST_SIZE_OR_ZERO]	= &scalar_types,
> +	[ARG_CONST_ALLOC_SIZE_OR_ZERO]	= &scalar_types,
> +	[ARG_CONST_MAP_PTR]		= &const_map_ptr_types,
> +	[ARG_PTR_TO_CTX]		= &context_types,
> +	[ARG_PTR_TO_CTX_OR_NULL]	= &context_types,
> +	[ARG_PTR_TO_SOCK_COMMON]	= &sock_types,
> +	[ARG_PTR_TO_SOCKET]		= &fullsock_types,
> +	[ARG_PTR_TO_SOCKET_OR_NULL]	= &fullsock_types,
> +	[ARG_PTR_TO_BTF_ID]		= &btf_ptr_types,
> +	[ARG_PTR_TO_SPIN_LOCK]		= &spin_lock_types,
> +	[ARG_PTR_TO_MEM]		= &mem_types,
> +	[ARG_PTR_TO_MEM_OR_NULL]	= &mem_types,
> +	[ARG_PTR_TO_UNINIT_MEM]		= &mem_types,
> +	[ARG_PTR_TO_ALLOC_MEM]		= &alloc_mem_types,
> +	[ARG_PTR_TO_ALLOC_MEM_OR_NULL]	= &alloc_mem_types,
> +	[ARG_PTR_TO_INT]		= &int_ptr_types,
> +	[ARG_PTR_TO_LONG]		= &int_ptr_types,
> +	[__BPF_ARG_TYPE_MAX]		= NULL,

I don't understand what this extra value is for.
I tried:
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index fc5c901c7542..87b0d5dcc1ff 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -292,7 +292,6 @@ enum bpf_arg_type {
        ARG_PTR_TO_ALLOC_MEM,   /* pointer to dynamically allocated memory */
        ARG_PTR_TO_ALLOC_MEM_OR_NULL,   /* pointer to dynamically allocated memory or NULL */
        ARG_CONST_ALLOC_SIZE_OR_ZERO,   /* number of allocated bytes requested */
-       __BPF_ARG_TYPE_MAX,
 };

 /* type of values returned from helper functions */
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 15ab889b0a3f..83faa67858b6 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -4025,7 +4025,6 @@ static const struct bpf_reg_types *compatible_reg_types[] = {
        [ARG_PTR_TO_ALLOC_MEM_OR_NULL]  = &alloc_mem_types,
        [ARG_PTR_TO_INT]                = &int_ptr_types,
        [ARG_PTR_TO_LONG]               = &int_ptr_types,
-       [__BPF_ARG_TYPE_MAX]            = NULL,
 };

and everything is fine as I think it should be.

> +	compatible = compatible_reg_types[arg_type];
> +	if (!compatible) {
> +		verbose(env, "verifier internal error: unsupported arg type %d\n", arg_type);
>  		return -EFAULT;
>  	}

This check will trigger the same way when somebody adds new ARG_* and doesn't add to the table.

>  
> +	err = check_reg_type(env, regno, compatible);
> +	if (err)
> +		return err;
> +
>  	if (type == PTR_TO_BTF_ID) {
>  		const u32 *btf_id = fn->arg_btf_id[arg];
>  
> @@ -4174,10 +4213,6 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 arg,
>  	}
>  
>  	return err;
> -err_type:
> -	verbose(env, "R%d type=%s expected=%s\n", regno,
> -		reg_type_str[type], reg_type_str[expected_type]);
> -	return -EACCES;

I'm not a fan of table driven checks. I think one explicit switch statement
would have been easier to read, but I guess we can convert back to it later if
table becomes too limiting. The improvement in the verifier output is important
and justifies this approach.

Applied to bpf-next. Thanks!