| /linux/Documentation/bpf/ |
| H A D | graph_ds_impl.rst | 6 structures (linked_list, rbtree), with particular focus on the verifier's
9 Although no specific verifier code is referred to in this document, the document
10 assumes that the reader has general knowledge of BPF verifier internals, BPF
37 "node"s, the verifier code and this document refer to common functionality
75 variables are placed in a single-value arraymap. The verifier considers this
98 From the verifier's perspective, the pointer ``n`` returned from ``bpf_obj_new``
109 What should the verifier do with ``n`` after ownership is passed off? If the
110 object was ``free``'d with ``bpf_obj_drop`` the answer is obvious: the verifier
116 obvious. The verifier could enforce the same semantics as for ``bpf_obj_drop``,
133 Both the read from and write to ``n->data`` would be rejected. The verifier
[all …]
|
| H A D | kfuncs.rst | 76 that to the verifier:
120 by the verifier to make the usage of kernel functions safer and more useful.
135 Here, the verifier will treat first argument as a PTR_TO_MEM, and second
144 the verifier must check the scalar argument to be a known constant, which does
158 values don't match during verifier state pruning checks.
178 annotation, the verifier will reject the program if the dynptr passed in is
185 The verifier will allow passing NULL for such arguments.
199 verifier will skip size validation when a NULL pointer is passed, but will
257 verifier-known map from an opaque one.
314 However, there is no obligation to prove to the verifier that such a pointer is
[all …]
|
| H A D | signing.rst | 25 capability checks or the verifier. A signed load still requires the usual
28 checked by the verifier like any other program. A valid signature establishes
49 instructions the verifier ends up checking, and the relocated form cannot be
111 accessed by a program whose digest matches that hash. The verifier enforces
135 #. Signature verification runs inside the verifier (``bpf_check()``), once it
144 frozen, or not a plain array is rejected, with a verifier log message naming
166 verifier as usual; because that check runs while ``fd_array`` is resolved -
167 before the verifier would otherwise compute the tag - ``prog->digest`` is
168 computed up front in the verifier, over the unmodified (signature-covered)
171 Coverage is then enforced as the verifier resolves instructions, at the point
[all …]
|
| H A D | bpf_design_QA.rst | 90 Q: What are the verifier limits?
94 program can have. The verifier has various internal limits.
100 calls, a limit to the number of the verifier states per instruction,
104 to be rejected. The verifier used to recognize only pointer + constant
108 The verifier is steadily getting 'smarter'. The limits are
110 be accepted by the verifier is to try to load it.
178 compiling a program. Furthermore, the verifier can now mark the
186 enable zext insertion in the verifier).
189 support for zext. In that case, if verifier zext insertion is enabled,
225 space, but the verifier computes the actual amount of stack used
[all …]
|
| H A D | index.rst | 15 verifier
|
| H A D | clang-notes.rst | 27 instruction, which is not supported by the Linux kernel verifier.
|
| H A D | ringbuf.rst | 49 infrastructure that has to be built for observability and verifier support. It
98 submit records of the length that's not known to verifier beforehand. It also
107 be reserved, such that verifier can verify that BPF program can't access memory
118 Each reserved record is tracked by verifier through existing
175 header. This significantly simplifies verifier, as well as improving API
|
| H A D | prog_lsm.rst | 90 the BPF verifier to update the offsets for the access at runtime using the
91 Documentation/bpf/btf.rst information. Since the BPF verifier is aware of the
|
| H A D | bpf_devel_QA.rst | 250 Q: I made a BPF verifier change, do I need to add test cases for
253 A: If the patch has changes to the behavior of the verifier, then yes,
262 affect prior use-cases. Thus, treat those test cases as: verifier
462 To run the verifier tests::
466 The verifier tests print out all the current checks being
519 existing ones are adapted to verifier changes e.g. due to verifier
587 generation back end or about LLVM generated code that the verifier
697 into these structures is verified by the BPF verifier and may result
|
| H A D | linux-notes.rst | 20 by the verifier. Any programs with this instruction will fail to load
|
| H A D | map_cpumap.rst | 51 program will result in the program failing to load and a verifier warning.
|
| H A D | prog_flow_dissector.rst | 14 in BPF to gain all the benefits of BPF verifier (namely, limits on the
|
| H A D | map_xskmap.rst | 90 result in the program failing to load and a verifier warning.
|
| /linux/tools/testing/selftests/bpf/ |
| H A D | veristat.cfg | 2 # BPF verifier's performance on
|
| H A D | README.rst | 137 // the instructions below will not be seen in the verifier log
142 The verifier will reject such code with above error.
145 verifier to understand such speculative pointer arithmetic.
206 The verifier output looks like
234 This cause later verifier failure. The bug has been `fixed`__ in
|
| H A D | Makefile | 923 verifier/tests.h: verifier/*.c
924 $(shell ( cd verifier/; \
929 ) > verifier/tests.h)
930 $(OUTPUT)/test_verifier: test_verifier.c verifier/tests.h $(BPFOBJ) | $(OUTPUT)
1041 prog_tests/tests.h map_tests/tests.h verifier/tests.h \
|
| /linux/tools/bpf/bpftool/Documentation/ |
| H A D | common_options.rst | 23 from libbpf as well as from the verifier, when attempting to load programs.
|
| /linux/drivers/net/ethernet/netronome/nfp/ |
| H A D | Makefile | 71 bpf/verifier.o \
|
| /linux/kernel/bpf/ |
| H A D | Makefile | 9 obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o cnum.o log.o token.o liv…
|
| /linux/Documentation/filesystems/nfs/ |
| H A D | client-identifier.rst | 56 - boot verifier: A 64-bit incarnation verifier that enables a
98 client presents a different boot verifier, so it appears to the
|
| /linux/fs/nfs/ |
| H A D | localio.c | 718 nfs_copy_boot_verifier(struct nfs_write_verifier *verifier, struct inode *inode) in nfs_copy_boot_verifier() argument
721 u32 *verf = (u32 *)verifier->data; in nfs_copy_boot_verifier()
746 nfs_copy_boot_verifier(&verf->verifier, inode); in nfs_set_local_verifier()
|
| /linux/Documentation/filesystems/xfs/ |
| H A D | xfs-self-describing-metadata.rst | 221 A typical buffer read verifier is structured as follows::
244 The verifier function will take a couple of different forms, depending on
272 If there are different magic numbers for the different formats, the verifier
298 the opposite order to the read verifiers. A typical write verifier::
|
| /linux/samples/bpf/ |
| H A D | README.rst | 4 This directory contains a test stubs, verifier test-suite and examples
|
| /linux/fs/nfsd/ |
| H A D | nfs3proc.c | 330 u32 *verifier = (u32 *)argp->verf; in nfsd3_create_file() local
337 v_mtime = verifier[0] & 0x7fffffff; in nfsd3_create_file()
338 v_atime = verifier[1] & 0x7fffffff; in nfsd3_create_file()
|
| H A D | trace.h | 993 __array(unsigned char, verifier, NFS4_VERIFIER_SIZE)
1001 memcpy(__entry->verifier, nn->writeverf,
1006 __print_hex_str(__entry->verifier, NFS4_VERIFIER_SIZE)
1079 __array(unsigned char, verifier, NFS4_VERIFIER_SIZE)
1088 memcpy(__entry->verifier, (void *)&clp->cl_verifier,
1094 __print_hex_str(__entry->verifier, NFS4_VERIFIER_SIZE),
|