On Tue, Jun 28, 2022 at 04:01:17PM +0000, Daniel Müller wrote:
> This patch set proposes the addition of a new way for performing type queries to
> BPF. It introduces the "type matches" relation, similar to what is already
> present with "type exists" (in the form of bpf_core_type_exists).
>
> "type exists" performs fairly superficial checking, mostly concerned with
> whether a type exists in the kernel and is of the same kind (enum/struct/...).
> Notably, compatibility checks for members of composite types is lacking.
>
> The newly introduced "type matches" (bpf_core_type_matches) fills this gap in
> that it performs stricter checks: compatibility of members and existence of
> similarly named enum variants is checked as well. E.g., given these definitions:
>
> struct task_struct___og { int pid; int tgid; };
>
> struct task_struct___foo { int foo; }
>
> 'task_struct___og' would "match" the kernel type 'task_struct', because the
> members match up, while 'task_struct___foo' would not match, because the
> kernel's 'task_struct' has no member named 'foo'.
>
> More precisely, the "type match" relation is defined as follows (copied from
> source):
> - modifiers and typedefs are stripped (and, hence, effectively ignored)
> - generally speaking types need to be of same kind (struct vs. struct, union
> vs. union, etc.)
> - exceptions are struct/union behind a pointer which could also match a
> forward declaration of a struct or union, respectively, and enum vs.
> enum64 (see below)
> Then, depending on type:
> - integers:
> - match if size and signedness match
> - arrays & pointers:
> - target types are recursively matched
> - structs & unions:
> - local members need to exist in target with the same name
> - for each member we recursively check match unless it is already behind a
> pointer, in which case we only check matching names and compatible kind
> - enums:
> - local variants have to have a match in target by symbolic name (but not
> numeric value)
> - size has to match (but enum may match enum64 and vice versa)
> - function pointers:
> - number and position of arguments in local type has to match target
> - for each argument and the return value we recursively check match
>
> Enabling this feature requires a new relocation to be made known to the
> compiler. This is being taken care of for LLVM as part of
> https://reviews.llvm.org/D126838.
To give an update here, LLVM changes have been merged and, to the best of my
knowledge, are being used by BPF CI (tests that failed earlier are now passing).
Thanks,
Daniel
[...]
