bpf: Allow trusted args to walk struct when checking BTF IDs
When validating BTF types for KF_TRUSTED_ARGS kfuncs, the verifier currently enforces that the top-level type must match when calling the kfunc. In other words, the verifier does not allow the BPF program to pass a bitwise equivalent struct, despite it being allowed according to the C standard. For example, if you have the following type: struct nf_conn___init { struct nf_conn ct; }; The C standard stipulates that it would be safe to pass a struct nf_conn___init to a kfunc expecting a struct nf_conn. The verifier currently disallows this, however, as semantically kfuncs may want to enforce that structs that have equivalent types according to the C standard, but have different BTF IDs, are not able to be passed to kfuncs expecting one or the other. For example, struct nf_conn___init may not be queried / looked up, as it is allocated but may not yet be fully initialized. On the other hand, being able to pass types that are equivalent according to the C standard will be useful for other types of kfunc / kptrs enabled by BPF. For example, in a follow-on patch, a series of kfuncs will be added which allow programs to do bitwise queries on cpumasks that are either allocated by the program (in which case they'll be a 'struct bpf_cpumask' type that wraps a cpumask_t as its first element), or a cpumask that was allocated by the main kernel (in which case it will just be a straight cpumask_t, as in task->cpus_ptr). Having the two types of cpumasks allows us to distinguish between the two for when a cpumask is read-only vs. mutatable. A struct bpf_cpumask can be mutated by e.g. bpf_cpumask_clear(), whereas a regular cpumask_t cannot be. On the other hand, a struct bpf_cpumask can of course be queried in the exact same manner as a cpumask_t, with e.g. bpf_cpumask_test_cpu(). If we were to enforce that top level types match, then a user that's passing a struct bpf_cpumask to a read-only cpumask_t argument would have to cast with something like bpf_cast_to_kern_ctx() (which itself would need to be updated to expect the alias, and currently it only accommodates a single alias per prog type). Additionally, not specifying KF_TRUSTED_ARGS is not an option, as some kfuncs take one argument as a struct bpf_cpumask *, and another as a struct cpumask * (i.e. cpumask_t). In order to enable this, this patch relaxes the constraint that a KF_TRUSTED_ARGS kfunc must have strict type matching, and instead only enforces strict type matching if a type is observed to be a "no-cast alias" (i.e., that the type names are equivalent, but one is suffixed with ___init). Additionally, in order to try and be conservative and match existing behavior / expectations, this patch also enforces strict type checking for acquire kfuncs. We were already enforcing it for release kfuncs, so this should also improve the consistency of the semantics for kfuncs. Signed-off-by: David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20230120192523.3650503-3-void@manifault.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
This commit is contained in:
parent
57539b1c0a
commit
b613d335a7
@ -2191,6 +2191,10 @@ bool btf_nested_type_is_trusted(struct bpf_verifier_log *log,
|
||||
const struct bpf_reg_state *reg,
|
||||
int off);
|
||||
|
||||
bool btf_type_ids_nocast_alias(struct bpf_verifier_log *log,
|
||||
const struct btf *reg_btf, u32 reg_id,
|
||||
const struct btf *arg_btf, u32 arg_id);
|
||||
|
||||
int bpf_core_apply(struct bpf_core_ctx *ctx, const struct bpf_core_relo *relo,
|
||||
int relo_idx, void *insn);
|
||||
|
||||
|
@ -336,6 +336,12 @@ const char *btf_type_str(const struct btf_type *t)
|
||||
/* Type name size */
|
||||
#define BTF_SHOW_NAME_SIZE 80
|
||||
|
||||
/*
|
||||
* The suffix of a type that indicates it cannot alias another type when
|
||||
* comparing BTF IDs for kfunc invocations.
|
||||
*/
|
||||
#define NOCAST_ALIAS_SUFFIX "___init"
|
||||
|
||||
/*
|
||||
* Common data to all BTF show operations. Private show functions can add
|
||||
* their own data to a structure containing a struct btf_show and consult it
|
||||
@ -8288,3 +8294,58 @@ bool btf_nested_type_is_trusted(struct bpf_verifier_log *log,
|
||||
|
||||
return false;
|
||||
}
|
||||
|
||||
bool btf_type_ids_nocast_alias(struct bpf_verifier_log *log,
|
||||
const struct btf *reg_btf, u32 reg_id,
|
||||
const struct btf *arg_btf, u32 arg_id)
|
||||
{
|
||||
const char *reg_name, *arg_name, *search_needle;
|
||||
const struct btf_type *reg_type, *arg_type;
|
||||
int reg_len, arg_len, cmp_len;
|
||||
size_t pattern_len = sizeof(NOCAST_ALIAS_SUFFIX) - sizeof(char);
|
||||
|
||||
reg_type = btf_type_by_id(reg_btf, reg_id);
|
||||
if (!reg_type)
|
||||
return false;
|
||||
|
||||
arg_type = btf_type_by_id(arg_btf, arg_id);
|
||||
if (!arg_type)
|
||||
return false;
|
||||
|
||||
reg_name = btf_name_by_offset(reg_btf, reg_type->name_off);
|
||||
arg_name = btf_name_by_offset(arg_btf, arg_type->name_off);
|
||||
|
||||
reg_len = strlen(reg_name);
|
||||
arg_len = strlen(arg_name);
|
||||
|
||||
/* Exactly one of the two type names may be suffixed with ___init, so
|
||||
* if the strings are the same size, they can't possibly be no-cast
|
||||
* aliases of one another. If you have two of the same type names, e.g.
|
||||
* they're both nf_conn___init, it would be improper to return true
|
||||
* because they are _not_ no-cast aliases, they are the same type.
|
||||
*/
|
||||
if (reg_len == arg_len)
|
||||
return false;
|
||||
|
||||
/* Either of the two names must be the other name, suffixed with ___init. */
|
||||
if ((reg_len != arg_len + pattern_len) &&
|
||||
(arg_len != reg_len + pattern_len))
|
||||
return false;
|
||||
|
||||
if (reg_len < arg_len) {
|
||||
search_needle = strstr(arg_name, NOCAST_ALIAS_SUFFIX);
|
||||
cmp_len = reg_len;
|
||||
} else {
|
||||
search_needle = strstr(reg_name, NOCAST_ALIAS_SUFFIX);
|
||||
cmp_len = arg_len;
|
||||
}
|
||||
|
||||
if (!search_needle)
|
||||
return false;
|
||||
|
||||
/* ___init suffix must come at the end of the name */
|
||||
if (*(search_needle + pattern_len) != '\0')
|
||||
return false;
|
||||
|
||||
return !strncmp(reg_name, arg_name, cmp_len);
|
||||
}
|
||||
|
@ -8820,9 +8820,37 @@ static int process_kf_arg_ptr_to_btf_id(struct bpf_verifier_env *env,
|
||||
reg_ref_id = *reg2btf_ids[base_type(reg->type)];
|
||||
}
|
||||
|
||||
if (is_kfunc_trusted_args(meta) || (is_kfunc_release(meta) && reg->ref_obj_id))
|
||||
/* Enforce strict type matching for calls to kfuncs that are acquiring
|
||||
* or releasing a reference, or are no-cast aliases. We do _not_
|
||||
* enforce strict matching for plain KF_TRUSTED_ARGS kfuncs by default,
|
||||
* as we want to enable BPF programs to pass types that are bitwise
|
||||
* equivalent without forcing them to explicitly cast with something
|
||||
* like bpf_cast_to_kern_ctx().
|
||||
*
|
||||
* For example, say we had a type like the following:
|
||||
*
|
||||
* struct bpf_cpumask {
|
||||
* cpumask_t cpumask;
|
||||
* refcount_t usage;
|
||||
* };
|
||||
*
|
||||
* Note that as specified in <linux/cpumask.h>, cpumask_t is typedef'ed
|
||||
* to a struct cpumask, so it would be safe to pass a struct
|
||||
* bpf_cpumask * to a kfunc expecting a struct cpumask *.
|
||||
*
|
||||
* The philosophy here is similar to how we allow scalars of different
|
||||
* types to be passed to kfuncs as long as the size is the same. The
|
||||
* only difference here is that we're simply allowing
|
||||
* btf_struct_ids_match() to walk the struct at the 0th offset, and
|
||||
* resolve types.
|
||||
*/
|
||||
if (is_kfunc_acquire(meta) ||
|
||||
(is_kfunc_release(meta) && reg->ref_obj_id) ||
|
||||
btf_type_ids_nocast_alias(&env->log, reg_btf, reg_ref_id, meta->btf, ref_id))
|
||||
strict_type_match = true;
|
||||
|
||||
WARN_ON_ONCE(is_kfunc_trusted_args(meta) && reg->off);
|
||||
|
||||
reg_ref_t = btf_type_skip_modifiers(reg_btf, reg_ref_id, ®_ref_id);
|
||||
reg_ref_tname = btf_name_by_offset(reg_btf, reg_ref_t->name_off);
|
||||
if (!btf_struct_ids_match(&env->log, reg_btf, reg_ref_id, reg->off, meta->btf, ref_id, strict_type_match)) {
|
||||
|
Loading…
Reference in New Issue
Block a user