Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> writes:
>>
>> +int bpf_check_attach_target(struct bpf_verifier_log *log,
>> + const struct bpf_prog *prog,
>> + const struct bpf_prog *tgt_prog,
>> + u32 btf_id,
>> + struct btf_func_model *fmodel,
>> + long *tgt_addr,
>> + const char **tgt_name,
>> + const struct btf_type **tgt_type);
>
> So this is obviously an abomination of a function signature,
> especially for a one exported to other files.
>
> One candidate to remove would be tgt_type, which is supposed to be a
> derivative of target BTF (vmlinux or tgt_prog->btf) + btf_id,
> **except** (and that's how I found the bug below), in case of
> fentry/fexit programs attaching to "conservative" BPF functions, in
> which case what's stored in aux->attach_func_proto is different from
> what is passed into btf_distill_func_proto. So that's a bug already
> (you'll return NULL in some cases for tgt_type, while it has to always
> be non-NULL).
Okay, looked at this in more detail, and I don't think the refactored
code is doing anything different from the pre-refactor version?
Before we had this:
if (tgt_prog && conservative) {
prog->aux->attach_func_proto = NULL;
t = NULL;
}
and now we just have
if (tgt_prog && conservative)
t = NULL;
in bpf_check_attach_target(), which gets returned as tgt_type and
subsequently assigned to prog->aux->attach_func_proto.
> But related to that is fmodel. It seems like bpf_check_attach_target()
> has no interest in fmodel itself and is just passing it from
> btf_distill_func_proto(). So I was about to suggest dropping fmodel
> and calling btf_distill_func_proto() outside of
> bpf_check_attach_target(), but given the conservative + fentry/fexit
> quirk, it's probably going to be more confusing.
>
> So with all this, I suggest dropping the tgt_type output param
> altogether and let callers do a `btf__type_by_id(tgt_prog ?
> tgt_prog->aux->btf : btf_vmlinux, btf_id);`. That will both fix the
> bug and will make this function's signature just a tad bit less
> horrible.
Thought about this, but the logic also does a few transformations of the
type itself, e.g., this for bpf_trace_raw_tp:
tname += sizeof(prefix) - 1;
t = btf_type_by_id(btf, t->type);
if (!btf_type_is_ptr(t))
/* should never happen in valid vmlinux build */
return -EINVAL;
t = btf_type_by_id(btf, t->type);
if (!btf_type_is_func_proto(t))
/* should never happen in valid vmlinux build */
return -EINVAL;
so to catch this we really do have to return the type from the function
as well.
I do agree that the function signature is a tad on the long side, but I
couldn't think of any good way of making it smaller. I considered
replacing the last two return values with a boolean 'save' parameter,
that would just make it same the values directly in prog->aux; but I
actually find it easier to reason about a function that is strictly
checking things and returning the result, instead of 'sometimes modify'
semantics...
-Toke
