| /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 | verifier.rst | 3 eBPF verifier
18 If verifier sees an insn that does R2=R1, then R2 has now type
22 (In 'secure' mode verifier will reject any type of pointer arithmetic to make
60 A callback is used to customize verifier to restrict eBPF program access to only
68 If R6=PTR_TO_CTX, via is_valid_access() callback the verifier will know
70 the verifier will reject the program.
75 The verifier will allow eBPF program to read data from stack only after
78 Classic BPF verifier does similar check with M[0-15] memory slots.
92 The eBPF verifier will check that registers match argument constraints.
100 from safety point of view. The verifier will guarantee that the function is
[all …]
|
| H A D | kfuncs.rst | 57 by the verifier to make the usage of kernel functions safer and more useful.
72 Here, the verifier will treat first argument as a PTR_TO_MEM, and second
81 the verifier must check the scalar argument to be a known constant, which does
95 values don't match during verifier state pruning checks.
115 annotation, the verifier will reject the program if the dynptr passed in is
123 the verifier will not check that length is appropriate for the buffer. The kfunc is
135 annotation, the verifier will reject the program if a null pointer is passed in with
176 In addition to kfuncs' arguments, verifier may need more information about the
206 refcounted object. The verifier will then ensure that the pointer to the object
208 referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the
[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 | 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 | clang-notes.rst | 27 instruction, which is not supported by the Linux kernel verifier.
|
| 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
454 To run the verifier tests::
458 The verifier tests print out all the current checks being
508 existing ones are adapted to verifier changes e.g. due to verifier
576 generation back end or about LLVM generated code that the verifier
685 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
|
| /linux/fs/nfs/ |
| H A D | nfstrace.h | 327 const __be32 *verifier,
333 TP_ARGS(file, verifier, cookie, page_index, dtsize),
340 __array(char, verifier, NFS4_VERIFIER_SIZE)
355 memcpy(__entry->verifier, verifier,
358 memset(__entry->verifier, 0,
370 __entry->version, show_nfs4_verifier(__entry->verifier),
380 const __be32 *verifier, \
385 TP_ARGS(file, verifier, cookie, page_index, dtsize))
1358 __array(char, verifier, NFS4_VERIFIER_SIZE)
1373 memcpy(__entry->verifier,
[all …]
|
| H A D | nfs3xdr.c | 272 static __be32 *xdr_encode_cookieverf3(__be32 *p, const __be32 *verifier) in xdr_encode_cookieverf3() argument
274 memcpy(p, verifier, NFS3_COOKIEVERFSIZE); in xdr_encode_cookieverf3()
278 static int decode_cookieverf3(struct xdr_stream *xdr, __be32 *verifier) in decode_cookieverf3() argument
285 memcpy(verifier, p, NFS3_COOKIEVERFSIZE); in decode_cookieverf3()
294 static void encode_createverf3(struct xdr_stream *xdr, const __be32 *verifier) in encode_createverf3() argument
299 memcpy(p, verifier, NFS3_CREATEVERFSIZE); in encode_createverf3()
302 static int decode_writeverf3(struct xdr_stream *xdr, struct nfs_write_verifier *verifier) in decode_writeverf3() argument
309 memcpy(verifier->data, p, NFS3_WRITEVERFSIZE); in decode_writeverf3()
1026 encode_createverf3(xdr, args->verifier); in encode_createhow3()
1700 if (decode_writeverf3(xdr, &result->verf->verifier)) in decode_write3resok()
[all …]
|
| H A D | nfs42proc.c | 243 memcpy(&res->write_res.verifier, ©->verf, sizeof(copy->verf)); in handle_async_copy()
269 if (nfs_write_verifier_cmp(&res->write_res.verifier.verifier, in process_copy_commit()
270 &cres.verf->verifier)) { in process_copy_commit()
383 nfs_write_verifier_cmp(&res->write_res.verifier.verifier, in _nfs42_proc_copy()
384 &res->commit_res.verf->verifier)) { in _nfs42_proc_copy()
397 res->write_res.verifier.committed != NFS_FILE_SYNC) { in _nfs42_proc_copy()
|
| H A D | localio.c | 420 nfs_copy_boot_verifier(struct nfs_write_verifier *verifier, struct inode *inode) in nfs_copy_boot_verifier() argument
423 u32 *verf = (u32 *)verifier->data; in nfs_copy_boot_verifier()
449 nfs_copy_boot_verifier(&verf->verifier, inode); in nfs_set_local_verifier()
|
| H A D | callback_proc.c | 705 memcpy(&cp_state->verf.verifier.data[0], in nfs4_copy_cb_args()
706 &args->wr_writeverf.verifier.data[0], in nfs4_copy_cb_args()
|
| /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 | 811 verifier/tests.h: verifier/*.c
812 $(shell ( cd verifier/; \
817 ) > verifier/tests.h)
818 $(OUTPUT)/test_verifier: test_verifier.c verifier/tests.h $(BPFOBJ) | $(OUTPUT)
896 prog_tests/tests.h map_tests/tests.h verifier/tests.h \
|
| /linux/include/linux/ |
| H A D | nfs_xdr.h | 484 nfs4_verifier verifier; /* EXCLUSIVE */ member
660 struct nfs_write_verifier verifier; member
946 __be32 verifier[2]; member
1163 nfs4_verifier verifier; member
1173 nfs4_verifier verifier; member
1357 nfs4_verifier verifier; member
1504 struct nfs_writeverf verifier; member
|
| /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 log.o token.o
|
| /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/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/fs/nfsd/ |
| H A D | nfs3proc.c | 306 u32 *verifier = (u32 *)argp->verf; in nfsd3_create_file() local
313 v_mtime = verifier[0] & 0x7fffffff; in nfsd3_create_file()
314 v_atime = verifier[1] & 0x7fffffff; in nfsd3_create_file()
|