- 25 Jan, 2023 15 commits
-
-
David Vernet authored
In a prior change, the verifier was updated to support sleepable BPF_PROG_TYPE_STRUCT_OPS programs. A caller could set the program as sleepable with bpf_program__set_flags(), but it would be more ergonomic and more in-line with other sleepable program types if we supported suffixing a struct_ops section name with .s to indicate that it's sleepable. Signed-off-by:
David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20230125164735.785732-3-void@manifault.comSigned-off-by:
Alexei Starovoitov <ast@kernel.org>
-
David Vernet authored
BPF struct_ops programs currently cannot be marked as sleepable. This need not be the case -- struct_ops programs can be sleepable, and e.g. invoke kfuncs that export the KF_SLEEPABLE flag. So as to allow future struct_ops programs to invoke such kfuncs, this patch updates the verifier to allow struct_ops programs to be sleepable. A follow-on patch will add support to libbpf for specifying struct_ops.s as a sleepable struct_ops program, and then another patch will add testcases to the dummy_st_ops selftest suite which test sleepable struct_ops behavior. Signed-off-by:
-
Daniel T. Lee authored
As stated in README.rst, in order to resolve errors with linker errors, 'LDLIBS=-static' should be used. Most problems will be solved by this option, but in the case of urandom_read, this won't fix the problem. So the Makefile is currently implemented to strip the 'static' option when compiling the urandom_read. However, stripping this static option isn't configured properly on $(LDLIBS) correctly, which is now causing errors on static compilation. # LDLIBS=-static ./vmtest.sh ld.lld: error: attempted static link of dynamic object liburandom_read.so clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile:190: /linux/tools/testing/selftests/bpf/urandom_read] Error 1 make: *** Waiting for unfinished jobs.... This commit fixes this problem by configuring the strip with $(LDLIBS). Fixes: 68084a13 ("selftests/bpf: Fix building bpf selftests statically") Signed-off-by:Daniel T. Lee <danieltimlee@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20230125100440.21734-1-danieltimlee@gmail.com
-
Ian Rogers authored
HOSTCC is always wanted when building. Setting CC to HOSTCC happens after tools/scripts/Makefile.include is included, meaning flags are set assuming say CC is gcc, but then it can be later set to HOSTCC which may be clang. tools/scripts/Makefile.include is needed for host set up and common macros in objtool's Makefile. Rather than override CC to HOSTCC, just pass CC as HOSTCC to Makefile.build, the libsubcmd builds and the linkage step. This means the Makefiles don't see things like CC changing and tool flag determination, and similar, work properly. Also, clear the passed subdir as otherwise an outer build may break by inadvertently passing an inappropriate value. Signed-off-by:
Ian Rogers <irogers@google.com> Signed-off-by:
Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20230124064324.672022-2-irogers@google.com
-
Ian Rogers authored
Previously tools/lib/subcmd was added to the include path, switch to installing the headers and then including from that directory. This avoids dependencies on headers internal to tools/lib/subcmd. Add the missing subcmd directory to the affected #include. Signed-off-by:
-
Alexei Starovoitov authored
David Vernet says: ==================== This is part 3 of https://lore.kernel.org/all/20230119235833.2948341-1-void@manifault.com/ Part 2: https://lore.kernel.org/bpf/20230120192523.3650503-1-void@manifault.com/ This series is based off of commit b613d335 ("bpf: Allow trusted args to walk struct when checking BTF IDs"). Changelog: ---------- v2 -> v3: - Rebase onto master (commit described above). Only conflict that required resolution was updating the task_kfunc selftest suite error message location. - Put copyright onto one line in kernel/bpf/cpumask.c. - Remove now-unneeded pid-checking logic from progs/nested_trust_success.c. - Fix a couple of small grammatical typos in documentation. v1 -> v2: - Put back 'static' keyword in bpf_find_btf_id() (kernel test robot <lkp@intel.com>) - Surround cpumask kfuncs in __diag() blocks to avoid no-prototype build warnings (kernel test robot <lkp@intel.com>) - Enable ___init suffixes to a type definition to signal that a type is a nocast alias of another type. That is, that when passed to a kfunc that expects one of the two types, the verifier will reject the other even if they're equivalent according to the C standard (Kumar and Alexei) - Reject NULL for all trusted args, not just PTR_TO_MEM (Kumar) - Reject both NULL and PTR_MAYBE_NULL for all trusted args (Kumar and Alexei ) - Improve examples given in cpumask documentation (Alexei) - Use __success macro for nested_trust test (Alexei) - Fix comment typo in struct bpf_cpumask comment header. - Fix another example in the bpf_cpumask doc examples. - Add documentation for ___init suffix change mentioned above. ==================== Signed-off-by:
-
David Vernet authored
When comparing BTF IDs for pointers being passed to kfunc arguments, the verifier will allow pointer types that are equivalent according to the C standard. For example, for: struct bpf_cpumask { cpumask_t cpumask; refcount_t usage; }; The verifier will allow a struct bpf_cpumask * to be passed to a kfunc that takes a const struct cpumask * (cpumask_t is a typedef of struct cpumask). The exception to this rule is if a type is suffixed with ___init, such as: struct nf_conn___init { struct nf_conn ct; }; The verifier will _not_ allow a struct nf_conn___init * to be passed to a kfunc that expects a struct nf_conn *. This patch documents this behavior in the kfuncs documentation page. Signed-off-by: -
David Vernet authored
A prior change defined a new BTF_TYPE_SAFE_NESTED macro in the verifier which allows developers to specify when a pointee field in a struct type should inherit its parent pointer's trusted status. This patch updates the kfuncs documentation to specify this macro and how it can be used. Signed-off-by:
-
David Vernet authored
Now that we've added a series of new cpumask kfuncs, we should document them so users can easily use them. This patch adds a new cpumasks.rst file to document them. Signed-off-by:
-
David Vernet authored
A recent patch added a new set of kfuncs for allocating, freeing, manipulating, and querying cpumasks. This patch adds a new 'cpumask' selftest suite which verifies their behavior. Signed-off-by:
-
David Vernet authored
Now that defining trusted fields in a struct is supported, we should add selftests to verify the behavior. This patch adds a few such testcases. Signed-off-by:
-
David Vernet authored
Certain programs may wish to be able to query cpumasks. For example, if a program that is tracing percpu operations wishes to track which tasks end up running on which CPUs, it could be useful to associate that with the tasks' cpumasks. Similarly, programs tracking NUMA allocations, CPU scheduling domains, etc, could potentially benefit from being able to see which CPUs a task could be migrated to. This patch enables these types of use cases by introducing a series of bpf_cpumask_* kfuncs. Amongst these kfuncs, there are two separate "classes" of operations: 1. kfuncs which allow the caller to allocate and mutate their own cpumask kptrs in the form of a struct bpf_cpumask * object. Such kfuncs include e.g. bpf_cpumask_create() to allocate the cpumask, and bpf_cpumask_or() to mutate it. "Regular" cpumasks such as p->cpus_ptr may not be passed to these kfuncs, and the verifier will ensure this is the case by comparing BTF IDs. 2. Read-only operations which operate on const struct cpumask * arguments. For example, bpf_cpumask_test_cpu(), which tests whether a CPU is set in the cpumask. Any trusted struct cpumask * or struct bpf_cpumask * may be passed to these kfuncs. The verifier allows struct bpf_cpumask * even though the kfunc is defined with struct cpumask * because the first element of a struct bpf_cpumask is a cpumask_t, so it is safe to cast. A follow-on patch will add selftests which validate these kfuncs, and another will document them. Signed-off-by:
-
David Vernet authored
KF_TRUSTED_ARGS kfuncs currently have a subtle and insidious bug in validating pointers to scalars. Say that you have a kfunc like the following, which takes an array as the first argument: bool bpf_cpumask_empty(const struct cpumask *cpumask) { return cpumask_empty(cpumask); } ... BTF_ID_FLAGS(func, bpf_cpumask_empty, KF_TRUSTED_ARGS) ... If a BPF program were to invoke the kfunc with a NULL argument, it would crash the kernel. The reason is that struct cpumask is defined as a bitmap, which is itself defined as an array, and is accessed as a memory address by bitmap operations. So when the verifier analyzes the register, it interprets it as a pointer to a scalar struct, which is an array of size 8. check_mem_reg() then sees that the register is NULL and returns 0, and the kfunc crashes when it passes it down to the cpumask wrappers. To fix this, this patch adds a check for KF_ARG_PTR_TO_MEM which verifies that the register doesn't contain a possibly-NULL pointer if the kfunc is KF_TRUSTED_ARGS. Signed-off-by: -
David Vernet authored
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 authored
In kfuncs, a "trusted" pointer is a pointer that the kfunc can assume is safe, and which the verifier will allow to be passed to a KF_TRUSTED_ARGS kfunc. Currently, a KF_TRUSTED_ARGS kfunc disallows any pointer to be passed at a nonzero offset, but sometimes this is in fact safe if the "nested" pointer's lifetime is inherited from its parent. For example, the const cpumask_t *cpus_ptr field in a struct task_struct will remain valid until the task itself is destroyed, and thus would also be safe to pass to a KF_TRUSTED_ARGS kfunc. While it would be conceptually simple to enable this by using BTF tags, gcc unfortunately does not yet support this. In the interim, this patch enables support for this by using a type-naming convention. A new BTF_TYPE_SAFE_NESTED macro is defined in verifier.c which allows a developer to specify the nested fields of a type which are considered trusted if its parent is also trusted. The verifier is also updated to account for this. A patch with selftests will be added in a follow-on change, along with documentation for this feature. Signed-off-by:
-
- 24 Jan, 2023 1 commit
-
-
Dave Thaler authored
Fix modulo zero, division by zero, overflow, and underflow. Also clarify how a negative immediate value is used in unsigned division. Signed-off-by:
Dave Thaler <dthaler@microsoft.com> Signed-off-by:
-
- 23 Jan, 2023 24 commits
-
-
Daniel Borkmann authored
Andrii Nakryiko says: ==================== This patch set fixes and extends libbpf's bpf_tracing.h support for tracing arguments of kprobes/uprobes, and syscall as a special case. Depending on the architecture, anywhere between 3 and 8 arguments can be passed to a function in registers (so relevant to kprobes and uprobes), but before this patch set libbpf's macros in bpf_tracing.h only supported up to 5 arguments, which is limiting in practice. This patch set extends bpf_tracing.h to support up to 8 arguments, if architecture allows. This includes explicit PT_REGS_PARMx() macro family, as well as BPF_KPROBE() macro. Now, with tracing syscall arguments situation is sometimes quite different. For a lot of architectures syscall argument passing through registers differs from function call sequence at least a little. For i386 it differs *a lot*. This patch set addresses this issue across all currently supported architectures and hopefully fixes existing issues. syscall(2) manpage defines that either 6 or 7 arguments can be supported, depending on architecture, so libbpf defines 6 or 7 registers per architecture to be used to fetch syscall arguments. Also, BPF_UPROBE and BPF_URETPROBE are introduced as part of this patch set. They are aliases for BPF_KPROBE and BPF_KRETPROBE (as mechanics of argument fetching of kernel functions and user-space functions are identical), but it allows BPF users to have less confusing BPF-side code when working with uprobes. For both sets of changes selftests are extended to test these new register definitions to architecture-defined limits. Unfortunately I don't have ability to test it on all architectures, and BPF CI only tests 3 architecture (x86-64, arm64, and s390x), so it would be greatly appreciated if people with access to architectures other than above 3 helped review and test changes. ==================== Signed-off-by: -
Andrii Nakryiko authored
Each architecture supports at least 6 syscall argument registers, so now that specs for each architecture is defined in bpf_tracing.h, remove unnecessary macro overrides, which previously were required to keep existing BPF_KSYSCALL() uses compiling and working. Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
-
Andrii Nakryiko authored
Turns out splice() is one of the syscalls that's using current maximum number of arguments (six). This is perfect for testing, so extend bpf_syscall_macro selftest to also trace splice() syscall, using BPF_KSYSCALL() macro. This makes sure all the syscall argument register definitions are correct. Suggested-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Note that 7th arg is supported on 32-bit powerpc architecture, by not on powerpc64. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. We need PT_REGS_PARM1_[CORE_]SYSCALL macros overrides, similarly to s390x, due to orig_x0 not being present in UAPI's pt_regs, so we need to utilize BPF CO-RE and custom pt_regs___arm64 definition. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Note that we need custom overrides for PT_REGS_PARM1_[CORE_]SYSCALL macros due to the need to use BPF CO-RE and custom local pt_regs definitions to fetch orig_gpr2, storing 1st argument. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Define explicit table of registers used for syscall argument passing. Remove now unnecessary overrides of PT_REGS_PARM5_[CORE_]SYSCALL macros. Signed-off-by:
-
Andrii Nakryiko authored
Set up generic support in bpf_tracing.h for up to 7 syscall arguments tracing with BPF_KSYSCALL, which seems to be the limit according to syscall(2) manpage. Also change the way that syscall convention is specified to be more explicit. Subsequent patches will adjust and define proper per-architecture syscall conventions. __PT_PARM1_SYSCALL_REG through __PT_PARM6_SYSCALL_REG is added temporarily to keep everything working before each architecture has syscall reg tables defined. They will be removed afterwards. Signed-off-by:
-
Andrii Nakryiko authored
Update uprobe_autoattach selftest to validate architecture-specific argument passing through registers. Use new BPF_UPROBE and BPF_URETPROBE, and construct both BPF-side and user-space side in such a way that for different architectures we are fetching and checking different number of arguments, matching architecture-specific limit of how many registers are available for argument passing. Signed-off-by:
-
Andrii Nakryiko authored
Add BPF_UPROBE and BPF_URETPROBE macros, aliased to BPF_KPROBE and BPF_KRETPROBE, respectively. This makes uprobe-based BPF program code much less confusing, especially to people new to tracing, at no cost in terms of maintainability. We'll use this macro in selftests in subsequent patch. Signed-off-by:
-
Andrii Nakryiko authored
Add PARM6 through PARM8 definitions. Add kernel docs link describing ABI for LoongArch. Signed-off-by:
-
Andrii Nakryiko authored
Add PARM6 through PARM8 definitions. Also fix frame pointer (FP) register definition. Also leave a link to where to find ABI spec. Signed-off-by:
-
Andrii Nakryiko authored
Add PARM6 through PARM8 definitions for RISC V (riscv) arch. Leave the link for ABI doc for future reference. Signed-off-by:
-
Andrii Nakryiko authored
Add PARM6 definition for sparc architecture. Leave a link to calling convention documentation. Signed-off-by:
-
Andrii Nakryiko authored
Add definitions of PARM6 through PARM8 for powerpc architecture. Add also a link to a functiona call sequence documentation for future reference. Signed-off-by:
-
Andrii Nakryiko authored
Add registers for PARM6 through PARM8. Add a link to an ABI. We don't distinguish between O32, N32, and N64, so document that we assume N64 right now. Signed-off-by:
-
Andrii Nakryiko authored
Remove invalid support for PARM5 on 32-bit arm, as per ABI. Add three more argument registers for arm64. Also leave links to ABI specs for future reference. Signed-off-by:
-
