| blob | 84d1b62e5ecb413830c9d8bb0061127ae91b4255 |
1 .\" Copyright (C) 2015 Alexei Starovoitov <ast@kernel.org>
2 .\" and Copyright (C) 2015 Michael Kerrisk <mtk.manpages@gmail.com>
3 .\"
4 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
5 .\"
6 .TH BPF 2 2021-08-27 "Linux man-pages (unreleased)"
7 .SH NAME
8 bpf \- perform a command on an extended BPF map or program
9 .SH SYNOPSIS
10 .nf
11 .B #include <linux/bpf.h>
12 .PP
13 .BI "int bpf(int " cmd ", union bpf_attr *" attr ", unsigned int " size );
14 .fi
15 .SH DESCRIPTION
16 The
17 .BR bpf ()
18 system call performs a range of operations related to extended
19 Berkeley Packet Filters.
20 Extended BPF (or eBPF) is similar to
21 the original ("classic") BPF (cBPF) used to filter network packets.
22 For both cBPF and eBPF programs,
23 the kernel statically analyzes the programs before loading them,
24 in order to ensure that they cannot harm the running system.
25 .PP
26 eBPF extends cBPF in multiple ways, including the ability to call
27 a fixed set of in-kernel helper functions
28 .\" See 'enum bpf_func_id' in include/uapi/linux/bpf.h
29 (via the
30 .B BPF_CALL
31 opcode extension provided by eBPF)
32 and access shared data structures such as eBPF maps.
33 .\"
34 .SS Extended BPF Design/Architecture
35 eBPF maps are a generic data structure for storage of different data types.
36 Data types are generally treated as binary blobs, so a user just specifies
37 the size of the key and the size of the value at map-creation time.
38 In other words, a key/value for a given map can have an arbitrary structure.
39 .PP
40 A user process can create multiple maps (with key/value-pairs being
41 opaque bytes of data) and access them via file descriptors.
42 Different eBPF programs can access the same maps in parallel.
43 It's up to the user process and eBPF program to decide what they store
44 inside maps.
45 .PP
46 There's one special map type, called a program array.
47 This type of map stores file descriptors referring to other eBPF programs.
48 When a lookup in the map is performed, the program flow is
49 redirected in-place to the beginning of another eBPF program and does not
50 return back to the calling program.
51 The level of nesting has a fixed limit of 32,
52 .\" Defined by the kernel constant MAX_TAIL_CALL_CNT in include/linux/bpf.h
53 so that infinite loops cannot be crafted.
54 At run time, the program file descriptors stored in the map can be modified,
55 so program functionality can be altered based on specific requirements.
56 All programs referred to in a program-array map must
57 have been previously loaded into the kernel via
58 .BR bpf ().
59 If a map lookup fails, the current program continues its execution.
60 See
61 .B BPF_MAP_TYPE_PROG_ARRAY
62 below for further details.
63 .PP
64 Generally, eBPF programs are loaded by the user process and automatically
65 unloaded when the process exits.
66 In some cases, for example,
67 .BR tc\-bpf (8),
68 the program will continue to stay alive inside the kernel even after the
69 process that loaded the program exits.
70 In that case,
71 the tc subsystem holds a reference to the eBPF program after the
72 file descriptor has been closed by the user-space program.
73 Thus, whether a specific program continues to live inside the kernel
74 depends on how it is further attached to a given kernel subsystem
75 after it was loaded via
76 .BR bpf ().
77 .PP
78 Each eBPF program is a set of instructions that is safe to run until
79 its completion.
80 An in-kernel verifier statically determines that the eBPF program
81 terminates and is safe to execute.
82 During verification, the kernel increments reference counts for each of
83 the maps that the eBPF program uses,
84 so that the attached maps can't be removed until the program is unloaded.
85 .PP
86 eBPF programs can be attached to different events.
87 These events can be the arrival of network packets, tracing
88 events, classification events by network queueing disciplines
89 (for eBPF programs attached to a
90 .BR tc (8)
91 classifier), and other types that may be added in the future.
92 A new event triggers execution of the eBPF program, which
93 may store information about the event in eBPF maps.
94 Beyond storing data, eBPF programs may call a fixed set of
95 in-kernel helper functions.
96 .PP
97 The same eBPF program can be attached to multiple events and different
98 eBPF programs can access the same map:
99 .PP
100 .in +4n
101 .EX
102 tracing tracing tracing packet packet packet
103 event A event B event C on eth0 on eth1 on eth2
104 | | | | | \(ha
105 | | | | v |
106 \-\-> tracing <\-\- tracing socket tc ingress tc egress
107 prog_1 prog_2 prog_3 classifier action
108 | | | | prog_4 prog_5
109 |\-\-\- \-\-\-\-\-| |\-\-\-\-\-\-| map_3 | |
110 map_1 map_2 \-\-| map_4 |\-\-
111 .EE
112 .in
113 .\"
114 .SS Arguments
115 The operation to be performed by the
116 .BR bpf ()
117 system call is determined by the
118 .I cmd
119 argument.
120 Each operation takes an accompanying argument,
121 provided via
122 .IR attr ,
123 which is a pointer to a union of type
124 .I bpf_attr
125 (see below).
126 The unused fields and padding must be zeroed out before the call.
127 The
128 .I size
129 argument is the size of the union pointed to by
130 .IR attr .
131 .PP
132 The value provided in
133 .I cmd
134 is one of the following:
135 .TP
136 .B BPF_MAP_CREATE
137 Create a map and return a file descriptor that refers to the map.
138 The close-on-exec file descriptor flag (see
139 .BR fcntl (2))
140 is automatically enabled for the new file descriptor.
141 .TP
142 .B BPF_MAP_LOOKUP_ELEM
143 Look up an element by key in a specified map and return its value.
144 .TP
145 .B BPF_MAP_UPDATE_ELEM
146 Create or update an element (key/value pair) in a specified map.
147 .TP
148 .B BPF_MAP_DELETE_ELEM
149 Look up and delete an element by key in a specified map.
150 .TP
151 .B BPF_MAP_GET_NEXT_KEY
152 Look up an element by key in a specified map and return the key
153 of the next element.
154 .TP
155 .B BPF_PROG_LOAD
156 Verify and load an eBPF program,
157 returning a new file descriptor associated with the program.
158 The close-on-exec file descriptor flag (see
159 .BR fcntl (2))
160 is automatically enabled for the new file descriptor.
161 .IP
162 The
163 .I bpf_attr
164 union consists of various anonymous structures that are used by different
165 .BR bpf ()
166 commands:
167 .PP
168 .in +4n
169 .EX
170 union bpf_attr {
171 struct { /* Used by BPF_MAP_CREATE */
172 uint32_t map_type;
173 uint32_t key_size; /* size of key in bytes */
174 uint32_t value_size; /* size of value in bytes */
175 uint32_t max_entries; /* maximum number of entries
176 in a map */
177 };
179 struct { /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
180 commands */
181 uint32_t map_fd;
182 __aligned_u64 key;
183 union {
184 __aligned_u64 value;
185 __aligned_u64 next_key;
186 };
187 uint64_t flags;
188 };
190 struct { /* Used by BPF_PROG_LOAD */
191 uint32_t prog_type;
192 uint32_t insn_cnt;
193 __aligned_u64 insns; /* \(aqconst struct bpf_insn *\(aq */
194 __aligned_u64 license; /* \(aqconst char *\(aq */
195 uint32_t log_level; /* verbosity level of verifier */
196 uint32_t log_size; /* size of user buffer */
197 __aligned_u64 log_buf; /* user supplied \(aqchar *\(aq
198 buffer */
199 uint32_t kern_version;
200 /* checked when prog_type=kprobe
201 (since Linux 4.1) */
202 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
203 };
204 } __attribute__((aligned(8)));
205 .EE
206 .in
207 .\"
208 .SS eBPF maps
209 Maps are a generic data structure for storage of different types of data.
210 They allow sharing of data between eBPF kernel programs,
211 and also between kernel and user-space applications.
212 .PP
213 Each map type has the following attributes:
214 .IP * 3
215 type
216 .IP *
217 maximum number of elements
218 .IP *
219 key size in bytes
220 .IP *
221 value size in bytes
222 .PP
223 The following wrapper functions demonstrate how various
224 .BR bpf ()
225 commands can be used to access the maps.
226 The functions use the
227 .I cmd
228 argument to invoke different operations.
229 .TP
230 .B BPF_MAP_CREATE
231 The
232 .B BPF_MAP_CREATE
233 command creates a new map,
234 returning a new file descriptor that refers to the map.
235 .IP
236 .in +4n
237 .EX
238 int
239 bpf_create_map(enum bpf_map_type map_type,
240 unsigned int key_size,
241 unsigned int value_size,
242 unsigned int max_entries)
243 {
244 union bpf_attr attr = {
245 .map_type = map_type,
246 .key_size = key_size,
247 .value_size = value_size,
248 .max_entries = max_entries
249 };
251 return bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
252 }
253 .EE
254 .in
255 .IP
256 The new map has the type specified by
257 .IR map_type ,
258 and attributes as specified in
259 .IR key_size ,
260 .IR value_size ,
261 and
262 .IR max_entries .
263 On success, this operation returns a file descriptor.
264 On error, \-1 is returned and
265 .I errno
266 is set to
267 .BR EINVAL ,
268 .BR EPERM ,
269 or
270 .BR ENOMEM .
271 .IP
272 The
273 .I key_size
274 and
275 .I value_size
276 attributes will be used by the verifier during program loading
277 to check that the program is calling
278 .BR bpf_map_*_elem ()
279 helper functions with a correctly initialized
280 .I key
281 and to check that the program doesn't access the map element
282 .I value
283 beyond the specified
284 .IR value_size .
285 For example, when a map is created with a
286 .I key_size
287 of 8 and the eBPF program calls
288 .IP
289 .in +4n
290 .EX
291 bpf_map_lookup_elem(map_fd, fp \- 4)
292 .EE
293 .in
294 .IP
295 the program will be rejected,
296 since the in-kernel helper function
297 .IP
298 .in +4n
299 .EX
300 bpf_map_lookup_elem(map_fd, void *key)
301 .EE
302 .in
303 .IP
304 expects to read 8 bytes from the location pointed to by
305 .IR key ,
306 but the
307 .I fp\ \-\ 4
308 (where
309 .I fp
310 is the top of the stack)
311 starting address will cause out-of-bounds stack access.
312 .IP
313 Similarly, when a map is created with a
314 .I value_size
315 of 1 and the eBPF program contains
316 .IP
317 .in +4n
318 .EX
319 value = bpf_map_lookup_elem(...);
320 *(uint32_t *) value = 1;
321 .EE
322 .in
323 .IP
324 the program will be rejected, since it accesses the
325 .I value
326 pointer beyond the specified 1 byte
327 .I value_size
328 limit.
329 .IP
330 Currently, the following values are supported for
331 .IR map_type :
332 .IP
333 .in +4n
334 .EX
335 enum bpf_map_type {
336 BPF_MAP_TYPE_UNSPEC, /* Reserve 0 as invalid map type */
337 BPF_MAP_TYPE_HASH,
338 BPF_MAP_TYPE_ARRAY,
339 BPF_MAP_TYPE_PROG_ARRAY,
340 BPF_MAP_TYPE_PERF_EVENT_ARRAY,
341 BPF_MAP_TYPE_PERCPU_HASH,
342 BPF_MAP_TYPE_PERCPU_ARRAY,
343 BPF_MAP_TYPE_STACK_TRACE,
344 BPF_MAP_TYPE_CGROUP_ARRAY,
345 BPF_MAP_TYPE_LRU_HASH,
346 BPF_MAP_TYPE_LRU_PERCPU_HASH,
347 BPF_MAP_TYPE_LPM_TRIE,
348 BPF_MAP_TYPE_ARRAY_OF_MAPS,
349 BPF_MAP_TYPE_HASH_OF_MAPS,
350 BPF_MAP_TYPE_DEVMAP,
351 BPF_MAP_TYPE_SOCKMAP,
352 BPF_MAP_TYPE_CPUMAP,
353 BPF_MAP_TYPE_XSKMAP,
354 BPF_MAP_TYPE_SOCKHASH,
355 BPF_MAP_TYPE_CGROUP_STORAGE,
356 BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
357 BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
358 BPF_MAP_TYPE_QUEUE,
359 BPF_MAP_TYPE_STACK,
360 /* See /usr/include/linux/bpf.h for the full list. */
361 };
362 .EE
363 .in
364 .IP
365 .I map_type
366 selects one of the available map implementations in the kernel.
367 .\" FIXME We need an explanation of why one might choose each of
368 .\" these map implementations
369 For all map types,
370 eBPF programs access maps with the same
371 .BR bpf_map_lookup_elem ()
372 and
373 .BR bpf_map_update_elem ()
374 helper functions.
375 Further details of the various map types are given below.
376 .TP
377 .B BPF_MAP_LOOKUP_ELEM
378 The
379 .B BPF_MAP_LOOKUP_ELEM
380 command looks up an element with a given
381 .I key
382 in the map referred to by the file descriptor
383 .IR fd .
384 .IP
385 .in +4n
386 .EX
387 int
388 bpf_lookup_elem(int fd, const void *key, void *value)
389 {
390 union bpf_attr attr = {
391 .map_fd = fd,
392 .key = ptr_to_u64(key),
393 .value = ptr_to_u64(value),
394 };
396 return bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
397 }
398 .EE
399 .in
400 .IP
401 If an element is found,
402 the operation returns zero and stores the element's value into
403 .IR value ,
404 which must point to a buffer of
405 .I value_size
406 bytes.
407 .IP
408 If no element is found, the operation returns \-1 and sets
409 .I errno
410 to
411 .BR ENOENT .
412 .TP
413 .B BPF_MAP_UPDATE_ELEM
414 The
415 .B BPF_MAP_UPDATE_ELEM
416 command
417 creates or updates an element with a given
418 .I key/value
419 in the map referred to by the file descriptor
420 .IR fd .
421 .IP
422 .in +4n
423 .EX
424 int
425 bpf_update_elem(int fd, const void *key, const void *value,
426 uint64_t flags)
427 {
428 union bpf_attr attr = {
429 .map_fd = fd,
430 .key = ptr_to_u64(key),
431 .value = ptr_to_u64(value),
432 .flags = flags,
433 };
435 return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
436 }
437 .EE
438 .in
439 .IP
440 The
441 .I flags
442 argument should be specified as one of the following:
443 .RS
444 .TP
445 .B BPF_ANY
446 Create a new element or update an existing element.
447 .TP
448 .B BPF_NOEXIST
449 Create a new element only if it did not exist.
450 .TP
451 .B BPF_EXIST
452 Update an existing element.
453 .RE
454 .IP
455 On success, the operation returns zero.
456 On error, \-1 is returned and
457 .I errno
458 is set to
459 .BR EINVAL ,
460 .BR EPERM ,
461 .BR ENOMEM ,
462 or
463 .BR E2BIG .
464 .B E2BIG
465 indicates that the number of elements in the map reached the
466 .I max_entries
467 limit specified at map creation time.
468 .B EEXIST
469 will be returned if
470 .I flags
471 specifies
472 .B BPF_NOEXIST
473 and the element with
474 .I key
475 already exists in the map.
476 .B ENOENT
477 will be returned if
478 .I flags
479 specifies
480 .B BPF_EXIST
481 and the element with
482 .I key
483 doesn't exist in the map.
484 .TP
485 .B BPF_MAP_DELETE_ELEM
486 The
487 .B BPF_MAP_DELETE_ELEM
488 command
489 deletes the element whose key is
490 .I key
491 from the map referred to by the file descriptor
492 .IR fd .
493 .IP
494 .in +4n
495 .EX
496 int
497 bpf_delete_elem(int fd, const void *key)
498 {
499 union bpf_attr attr = {
500 .map_fd = fd,
501 .key = ptr_to_u64(key),
502 };
504 return bpf(BPF_MAP_DELETE_ELEM, &attr, sizeof(attr));
505 }
506 .EE
507 .in
508 .IP
509 On success, zero is returned.
510 If the element is not found, \-1 is returned and
511 .I errno
512 is set to
513 .BR ENOENT .
514 .TP
515 .B BPF_MAP_GET_NEXT_KEY
516 The
517 .B BPF_MAP_GET_NEXT_KEY
518 command looks up an element by
519 .I key
520 in the map referred to by the file descriptor
521 .I fd
522 and sets the
523 .I next_key
524 pointer to the key of the next element.
525 .IP
526 .in +4n
527 .EX
528 int
529 bpf_get_next_key(int fd, const void *key, void *next_key)
530 {
531 union bpf_attr attr = {
532 .map_fd = fd,
533 .key = ptr_to_u64(key),
534 .next_key = ptr_to_u64(next_key),
535 };
537 return bpf(BPF_MAP_GET_NEXT_KEY, &attr, sizeof(attr));
538 }
539 .EE
540 .in
541 .IP
542 If
543 .I key
544 is found, the operation returns zero and sets the
545 .I next_key
546 pointer to the key of the next element.
547 If
548 .I key
549 is not found, the operation returns zero and sets the
550 .I next_key
551 pointer to the key of the first element.
552 If
553 .I key
554 is the last element, \-1 is returned and
555 .I errno
556 is set to
557 .BR ENOENT .
558 Other possible
559 .I errno
560 values are
561 .BR ENOMEM ,
562 .BR EFAULT ,
563 .BR EPERM ,
564 and
565 .BR EINVAL .
566 This method can be used to iterate over all elements in the map.
567 .TP
568 .B close(map_fd)
569 Delete the map referred to by the file descriptor
570 .IR map_fd .
571 When the user-space program that created a map exits, all maps will
572 be deleted automatically (but see NOTES).
573 .\"
574 .SS eBPF map types
575 The following map types are supported:
576 .TP
577 .B BPF_MAP_TYPE_HASH
578 .\" commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475
579 Hash-table maps have the following characteristics:
580 .RS
581 .IP * 3
582 Maps are created and destroyed by user-space programs.
583 Both user-space and eBPF programs
584 can perform lookup, update, and delete operations.
585 .IP *
586 The kernel takes care of allocating and freeing key/value pairs.
587 .IP *
588 The
589 .BR map_update_elem ()
590 helper will fail to insert new element when the
591 .I max_entries
592 limit is reached.
593 (This ensures that eBPF programs cannot exhaust memory.)
594 .IP *
595 .BR map_update_elem ()
596 replaces existing elements atomically.
597 .RE
598 .IP
599 Hash-table maps are
600 optimized for speed of lookup.
601 .TP
602 .B BPF_MAP_TYPE_ARRAY
603 .\" commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3
604 Array maps have the following characteristics:
605 .RS
606 .IP * 3
607 Optimized for fastest possible lookup.
608 In the future the verifier/JIT compiler
609 may recognize lookup() operations that employ a constant key
610 and optimize it into constant pointer.
611 It is possible to optimize a non-constant
612 key into direct pointer arithmetic as well, since pointers and
613 .I value_size
614 are constant for the life of the eBPF program.
615 In other words,
616 .BR array_map_lookup_elem ()
617 may be 'inlined' by the verifier/JIT compiler
618 while preserving concurrent access to this map from user space.
619 .IP *
620 All array elements pre-allocated and zero initialized at init time
621 .IP *
622 The key is an array index, and must be exactly four bytes.
623 .IP *
624 .BR map_delete_elem ()
625 fails with the error
626 .BR EINVAL ,
627 since elements cannot be deleted.
628 .IP *
629 .BR map_update_elem ()
630 replaces elements in a
631 .B nonatomic
632 fashion;
633 for atomic updates, a hash-table map should be used instead.
634 There is however one special case that can also be used with arrays:
635 the atomic built-in
636 .B __sync_fetch_and_add()
637 can be used on 32 and 64 bit atomic counters.
638 For example, it can be
639 applied on the whole value itself if it represents a single counter,
640 or in case of a structure containing multiple counters, it could be
641 used on individual counters.
642 This is quite often useful for aggregation and accounting of events.
643 .RE
644 .IP
645 Among the uses for array maps are the following:
646 .RS
647 .IP * 3
648 As "global" eBPF variables: an array of 1 element whose key is (index) 0
649 and where the value is a collection of 'global' variables which
650 eBPF programs can use to keep state between events.
651 .IP *
652 Aggregation of tracing events into a fixed set of buckets.
653 .IP *
654 Accounting of networking events, for example, number of packets and packet
655 sizes.
656 .RE
657 .TP
658 .BR BPF_MAP_TYPE_PROG_ARRAY " (since Linux 4.2)"
659 A program array map is a special kind of array map whose map values
660 contain only file descriptors referring to other eBPF programs.
661 Thus, both the
662 .I key_size
663 and
664 .I value_size
665 must be exactly four bytes.
666 This map is used in conjunction with the
667 .BR bpf_tail_call ()
668 helper.
669 .IP
670 This means that an eBPF program with a program array map attached to it
671 can call from kernel side into
672 .IP
673 .in +4n
674 .EX
675 void bpf_tail_call(void *context, void *prog_map,
676 unsigned int index);
677 .EE
678 .in
679 .IP
680 and therefore replace its own program flow with the one from the program
681 at the given program array slot, if present.
682 This can be regarded as kind of a jump table to a different eBPF program.
683 The invoked program will then reuse the same stack.
684 When a jump into the new program has been performed,
685 it won't return to the old program anymore.
686 .IP
687 If no eBPF program is found at the given index of the program array
688 (because the map slot doesn't contain a valid program file descriptor,
689 the specified lookup index/key is out of bounds,
690 or the limit of 32
691 .\" MAX_TAIL_CALL_CNT
692 nested calls has been exceed),
693 execution continues with the current eBPF program.
694 This can be used as a fall-through for default cases.
695 .IP
696 A program array map is useful, for example, in tracing or networking, to
697 handle individual system calls or protocols in their own subprograms and
698 use their identifiers as an individual map index.
699 This approach may result in performance benefits,
700 and also makes it possible to overcome the maximum
701 instruction limit of a single eBPF program.
702 In dynamic environments,
703 a user-space daemon might atomically replace individual subprograms
704 at run-time with newer versions to alter overall program behavior,
705 for instance, if global policies change.
706 .\"
707 .SS eBPF programs
708 The
709 .B BPF_PROG_LOAD
710 command is used to load an eBPF program into the kernel.
711 The return value for this command is a new file descriptor associated
712 with this eBPF program.
713 .PP
714 .in +4n
715 .EX
716 char bpf_log_buf[LOG_BUF_SIZE];
718 int
719 bpf_prog_load(enum bpf_prog_type type,
720 const struct bpf_insn *insns, int insn_cnt,
721 const char *license)
722 {
723 union bpf_attr attr = {
724 .prog_type = type,
725 .insns = ptr_to_u64(insns),
726 .insn_cnt = insn_cnt,
727 .license = ptr_to_u64(license),
728 .log_buf = ptr_to_u64(bpf_log_buf),
729 .log_size = LOG_BUF_SIZE,
730 .log_level = 1,
731 };
733 return bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
734 }
735 .EE
736 .in
737 .PP
738 .I prog_type
739 is one of the available program types:
740 .IP
741 .in +4n
742 .EX
743 enum bpf_prog_type {
744 BPF_PROG_TYPE_UNSPEC, /* Reserve 0 as invalid
745 program type */
746 BPF_PROG_TYPE_SOCKET_FILTER,
747 BPF_PROG_TYPE_KPROBE,
748 BPF_PROG_TYPE_SCHED_CLS,
749 BPF_PROG_TYPE_SCHED_ACT,
750 BPF_PROG_TYPE_TRACEPOINT,
751 BPF_PROG_TYPE_XDP,
752 BPF_PROG_TYPE_PERF_EVENT,
753 BPF_PROG_TYPE_CGROUP_SKB,
754 BPF_PROG_TYPE_CGROUP_SOCK,
755 BPF_PROG_TYPE_LWT_IN,
756 BPF_PROG_TYPE_LWT_OUT,
757 BPF_PROG_TYPE_LWT_XMIT,
758 BPF_PROG_TYPE_SOCK_OPS,
759 BPF_PROG_TYPE_SK_SKB,
760 BPF_PROG_TYPE_CGROUP_DEVICE,
761 BPF_PROG_TYPE_SK_MSG,
762 BPF_PROG_TYPE_RAW_TRACEPOINT,
763 BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
764 BPF_PROG_TYPE_LWT_SEG6LOCAL,
765 BPF_PROG_TYPE_LIRC_MODE2,
766 BPF_PROG_TYPE_SK_REUSEPORT,
767 BPF_PROG_TYPE_FLOW_DISSECTOR,
768 /* See /usr/include/linux/bpf.h for the full list. */
769 };
770 .EE
771 .in
772 .PP
773 For further details of eBPF program types, see below.
774 .PP
775 The remaining fields of
776 .I bpf_attr
777 are set as follows:
778 .IP * 3
779 .I insns
780 is an array of
781 .I "struct bpf_insn"
782 instructions.
783 .IP *
784 .I insn_cnt
785 is the number of instructions in the program referred to by
786 .IR insns .
787 .IP *
788 .I license
789 is a license string, which must be GPL compatible to call helper functions
790 marked
791 .IR gpl_only .
792 (The licensing rules are the same as for kernel modules,
793 so that also dual licenses, such as "Dual BSD/GPL", may be used.)
794 .IP *
795 .I log_buf
796 is a pointer to a caller-allocated buffer in which the in-kernel
797 verifier can store the verification log.
798 This log is a multi-line string that can be checked by
799 the program author in order to understand how the verifier came to
800 the conclusion that the eBPF program is unsafe.
801 The format of the output can change at any time as the verifier evolves.
802 .IP *
803 .I log_size
804 size of the buffer pointed to by
805 .IR log_buf .
806 If the size of the buffer is not large enough to store all
807 verifier messages, \-1 is returned and
808 .I errno
809 is set to
810 .BR ENOSPC .
811 .IP *
812 .I log_level
813 verbosity level of the verifier.
814 A value of zero means that the verifier will not provide a log;
815 in this case,
816 .I log_buf
817 must be a NULL pointer, and
818 .I log_size
819 must be zero.
820 .PP
821 Applying
822 .BR close (2)
823 to the file descriptor returned by
824 .B BPF_PROG_LOAD
825 will unload the eBPF program (but see NOTES).
826 .PP
827 Maps are accessible from eBPF programs and are used to exchange data between
828 eBPF programs and between eBPF programs and user-space programs.
829 For example,
830 eBPF programs can process various events (like kprobe, packets) and
831 store their data into a map,
832 and user-space programs can then fetch data from the map.
833 Conversely, user-space programs can use a map as a configuration mechanism,
834 populating the map with values checked by the eBPF program,
835 which then modifies its behavior on the fly according to those values.
836 .\"
837 .\"
838 .SS eBPF program types
839 The eBPF program type
840 .RI ( prog_type )
841 determines the subset of kernel helper functions that the program
842 may call.
843 The program type also determines the program input (context)\(emthe
844 format of
845 .I "struct bpf_context"
846 (which is the data blob passed into the eBPF program as the first argument).
847 .\"
848 .\" FIXME
849 .\" Somewhere in this page we need a general introduction to the
850 .\" bpf_context. For example, how does a BPF program access the
851 .\" context?
852 .PP
853 For example, a tracing program does not have the exact same
854 subset of helper functions as a socket filter program
855 (though they may have some helpers in common).
856 Similarly,
857 the input (context) for a tracing program is a set of register values,
858 while for a socket filter it is a network packet.
859 .PP
860 The set of functions available to eBPF programs of a given type may increase
861 in the future.
862 .PP
863 The following program types are supported:
864 .TP
865 .BR BPF_PROG_TYPE_SOCKET_FILTER " (since Linux 3.19)"
866 Currently, the set of functions for
867 .B BPF_PROG_TYPE_SOCKET_FILTER
868 is:
869 .IP
870 .in +4n
871 .EX
872 bpf_map_lookup_elem(map_fd, void *key)
873 /* look up key in a map_fd */
874 bpf_map_update_elem(map_fd, void *key, void *value)
875 /* update key/value */
876 bpf_map_delete_elem(map_fd, void *key)
877 /* delete key in a map_fd */
878 .EE
879 .in
880 .IP
881 The
882 .I bpf_context
883 argument is a pointer to a
884 .IR "struct __sk_buff" .
885 .\" FIXME: We need some text here to explain how the program
886 .\" accesses __sk_buff.
887 .\" See 'struct __sk_buff' and commit 9bac3d6d548e5
888 .\"
889 .\" Alexei commented:
890 .\" Actually now in case of SOCKET_FILTER, SCHED_CLS, SCHED_ACT
891 .\" the program can now access skb fields.
892 .\"
893 .TP
894 .BR BPF_PROG_TYPE_KPROBE " (since Linux 4.1)"
895 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
896 [To be documented]
897 .\" FIXME Document this program type
898 .\" Describe allowed helper functions for this program type
899 .\" Describe bpf_context for this program type
900 .\"
901 .\" FIXME We need text here to describe 'kern_version'
902 .TP
903 .BR BPF_PROG_TYPE_SCHED_CLS " (since Linux 4.1)"
904 .\" commit 96be4325f443dbbfeb37d2a157675ac0736531a1
905 .\" commit e2e9b6541dd4b31848079da80fe2253daaafb549
906 [To be documented]
907 .\" FIXME Document this program type
908 .\" Describe allowed helper functions for this program type
909 .\" Describe bpf_context for this program type
910 .TP
911 .BR BPF_PROG_TYPE_SCHED_ACT " (since Linux 4.1)"
912 .\" commit 94caee8c312d96522bcdae88791aaa9ebcd5f22c
913 .\" commit a8cb5f556b567974d75ea29c15181c445c541b1f
914 [To be documented]
915 .\" FIXME Document this program type
916 .\" Describe allowed helper functions for this program type
917 .\" Describe bpf_context for this program type
918 .SS Events
919 Once a program is loaded, it can be attached to an event.
920 Various kernel subsystems have different ways to do so.
921 .PP
922 Since Linux 3.19,
923 .\" commit 89aa075832b0da4402acebd698d0411dcc82d03e
924 the following call will attach the program
925 .I prog_fd
926 to the socket
927 .IR sockfd ,
928 which was created by an earlier call to
929 .BR socket (2):
930 .PP
931 .in +4n
932 .EX
933 setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_BPF,
934 &prog_fd, sizeof(prog_fd));
935 .EE
936 .in
937 .PP
938 Since Linux 4.1,
939 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
940 the following call may be used to attach
941 the eBPF program referred to by the file descriptor
942 .I prog_fd
943 to a perf event file descriptor,
944 .IR event_fd ,
945 that was created by a previous call to
946 .BR perf_event_open (2):
947 .PP
948 .in +4n
949 .EX
950 ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
951 .EE
952 .in
953 .\"
954 .\"
955 .SH RETURN VALUE
956 For a successful call, the return value depends on the operation:
957 .TP
958 .B BPF_MAP_CREATE
959 The new file descriptor associated with the eBPF map.
960 .TP
961 .B BPF_PROG_LOAD
962 The new file descriptor associated with the eBPF program.
963 .TP
964 All other commands
965 Zero.
966 .PP
967 On error, \-1 is returned, and
968 .I errno
969 is set to indicate the error.
970 .SH ERRORS
971 .TP
972 .B E2BIG
973 The eBPF program is too large or a map reached the
974 .I max_entries
975 limit (maximum number of elements).
976 .TP
977 .B EACCES
978 For
979 .BR BPF_PROG_LOAD ,
980 even though all program instructions are valid, the program has been
981 rejected because it was deemed unsafe.
982 This may be because it may have
983 accessed a disallowed memory region or an uninitialized stack/register or
984 because the function constraints don't match the actual types or because
985 there was a misaligned memory access.
986 In this case, it is recommended to call
987 .BR bpf ()
988 again with
989 .I log_level = 1
990 and examine
991 .I log_buf
992 for the specific reason provided by the verifier.
993 .TP
994 .B EBADF
995 .I fd
996 is not an open file descriptor.
997 .TP
998 .B EFAULT
999 One of the pointers
1000 .RI ( key
1001 or
1002 .I value
1003 or
1004 .I log_buf
1005 or
1006 .IR insns )
1007 is outside the accessible address space.
1008 .TP
1009 .B EINVAL
1010 The value specified in
1011 .I cmd
1012 is not recognized by this kernel.
1013 .TP
1014 .B EINVAL
1015 For
1016 .BR BPF_MAP_CREATE ,
1017 either
1018 .I map_type
1019 or attributes are invalid.
1020 .TP
1021 .B EINVAL
1022 For
1023 .B BPF_MAP_*_ELEM
1024 commands,
1025 some of the fields of
1026 .I "union bpf_attr"
1027 that are not used by this command
1028 are not set to zero.
1029 .TP
1030 .B EINVAL
1031 For
1032 .BR BPF_PROG_LOAD ,
1033 indicates an attempt to load an invalid program.
1034 eBPF programs can be deemed
1035 invalid due to unrecognized instructions, the use of reserved fields, jumps
1036 out of range, infinite loops or calls of unknown functions.
1037 .TP
1038 .B ENOENT
1039 For
1040 .B BPF_MAP_LOOKUP_ELEM
1041 or
1042 .BR BPF_MAP_DELETE_ELEM ,
1043 indicates that the element with the given
1044 .I key
1045 was not found.
1046 .TP
1047 .B ENOMEM
1048 Cannot allocate sufficient memory.
1049 .TP
1050 .B EPERM
1051 The call was made without sufficient privilege
1052 (without the
1053 .B CAP_SYS_ADMIN
1054 capability).
1055 .SH VERSIONS
1056 The
1057 .BR bpf ()
1058 system call first appeared in Linux 3.18.
1059 .SH STANDARDS
1060 The
1061 .BR bpf ()
1062 system call is Linux-specific.
1063 .SH NOTES
1064 Prior to Linux 4.4, all
1065 .BR bpf ()
1066 commands require the caller to have the
1067 .B CAP_SYS_ADMIN
1068 capability.
1069 From Linux 4.4 onwards,
1070 .\" commit 1be7f75d1668d6296b80bf35dcf6762393530afc
1071 an unprivileged user may create limited programs of type
1072 .B BPF_PROG_TYPE_SOCKET_FILTER
1073 and associated maps.
1074 However they may not store kernel pointers within
1075 the maps and are presently limited to the following helper functions:
1076 .\" [Linux 5.6] mtk: The list of available functions is, I think, governed
1077 .\" by the check in net/core/filter.c::bpf_base_func_proto().
1078 .IP * 3
1079 get_random
1080 .PD 0
1081 .IP *
1082 get_smp_processor_id
1083 .IP *
1084 tail_call
1085 .IP *
1086 ktime_get_ns
1087 .PD 1
1088 .PP
1089 Unprivileged access may be blocked by writing the value 1 to the file
1090 .IR /proc/sys/kernel/unprivileged_bpf_disabled .
1091 .PP
1092 eBPF objects (maps and programs) can be shared between processes.
1093 For example, after
1094 .BR fork (2),
1095 the child inherits file descriptors referring to the same eBPF objects.
1096 In addition, file descriptors referring to eBPF objects can be
1097 transferred over UNIX domain sockets.
1098 File descriptors referring to eBPF objects can be duplicated
1099 in the usual way, using
1100 .BR dup (2)
1101 and similar calls.
1102 An eBPF object is deallocated only after all file descriptors
1103 referring to the object have been closed.
1104 .PP
1105 eBPF programs can be written in a restricted C that is compiled (using the
1106 .B clang
1107 compiler) into eBPF bytecode.
1108 Various features are omitted from this restricted C, such as loops,
1109 global variables, variadic functions, floating-point numbers,
1110 and passing structures as function arguments.
1111 Some examples can be found in the
1112 .I samples/bpf/*_kern.c
1113 files in the kernel source tree.
1114 .\" There are also examples for the tc classifier, in the iproute2
1115 .\" project, in examples/bpf
1116 .PP
1117 The kernel contains a just-in-time (JIT) compiler that translates
1118 eBPF bytecode into native machine code for better performance.
1119 In kernels before Linux 4.15,
1120 the JIT compiler is disabled by default,
1121 but its operation can be controlled by writing one of the
1122 following integer strings to the file
1123 .IR /proc/sys/net/core/bpf_jit_enable :
1124 .IP 0 3
1125 Disable JIT compilation (default).
1126 .IP 1
1127 Normal compilation.
1128 .IP 2
1129 Debugging mode.
1130 The generated opcodes are dumped in hexadecimal into the kernel log.
1131 These opcodes can then be disassembled using the program
1132 .I tools/net/bpf_jit_disasm.c
1133 provided in the kernel source tree.
1134 .PP
1135 Since Linux 4.15,
1136 .\" commit 290af86629b25ffd1ed6232c4e9107da031705cb
1137 the kernel may configured with the
1138 .B CONFIG_BPF_JIT_ALWAYS_ON
1139 option.
1140 In this case, the JIT compiler is always enabled, and the
1141 .I bpf_jit_enable
1142 is initialized to 1 and is immutable.
1143 (This kernel configuration option was provided as a mitigation for
1144 one of the Spectre attacks against the BPF interpreter.)
1145 .PP
1146 The JIT compiler for eBPF is currently
1147 .\" Last reviewed in Linux 4.18-rc by grepping for BPF_ALU64 in arch/
1148 .\" and by checking the documentation for bpf_jit_enable in
1149 .\" Documentation/sysctl/net.txt
1150 available for the following architectures:
1151 .IP * 3
1152 x86-64 (since Linux 3.18; cBPF since Linux 3.0);
1153 .\" commit 0a14842f5a3c0e88a1e59fac5c3025db39721f74
1154 .PD 0
1155 .IP *
1156 ARM32 (since Linux 3.18; cBPF since Linux 3.4);
1157 .\" commit ddecdfcea0ae891f782ae853771c867ab51024c2
1158 .IP *
1159 SPARC 32 (since Linux 3.18; cBPF since Linux 3.5);
1160 .\" commit 2809a2087cc44b55e4377d7b9be3f7f5d2569091
1161 .IP *
1162 ARM-64 (since Linux 3.18);
1163 .\" commit e54bcde3d69d40023ae77727213d14f920eb264a
1164 .IP *
1165 s390 (since Linux 4.1; cBPF since Linux 3.7);
1166 .\" commit c10302efe569bfd646b4c22df29577a4595b4580
1167 .IP *
1168 PowerPC 64 (since Linux 4.8; cBPF since Linux 3.1);
1169 .\" commit 0ca87f05ba8bdc6791c14878464efc901ad71e99
1170 .\" commit 156d0e290e969caba25f1851c52417c14d141b24
1171 .IP *
1172 SPARC 64 (since Linux 4.12);
1173 .\" commit 7a12b5031c6b947cc13918237ae652b536243b76
1174 .IP *
1175 x86-32 (since Linux 4.18);
1176 .\" commit 03f5781be2c7b7e728d724ac70ba10799cc710d7
1177 .IP *
1178 MIPS 64 (since Linux 4.18; cBPF since Linux 3.16);
1179 .\" commit c6610de353da5ca6eee5b8960e838a87a90ead0c
1180 .\" commit f381bf6d82f032b7410185b35d000ea370ac706b
1181 .IP *
1182 riscv (since Linux 5.1).
1183 .\" commit 2353ecc6f91fd15b893fa01bf85a1c7a823ee4f2
1184 .PD
1185 .SH EXAMPLES
1186 .\" [[FIXME]] SRC BEGIN (bpf.c)
1187 .EX
1188 /* bpf+sockets example:
1189 * 1. create array map of 256 elements
1190 * 2. load program that counts number of packets received
1191 * r0 = skb\->data[ETH_HLEN + offsetof(struct iphdr, protocol)]
1192 * map[r0]++
1193 * 3. attach prog_fd to raw socket via setsockopt()
1194 * 4. print number of received TCP/UDP packets every second
1195 */
1196 int
1197 main(int argc, char *argv[])
1198 {
1199 int sock, map_fd, prog_fd, key;
1200 long long value = 0, tcp_cnt, udp_cnt;
1202 map_fd = bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(key),
1203 sizeof(value), 256);
1204 if (map_fd < 0) {
1205 printf("failed to create map \(aq%s\(aq\en", strerror(errno));
1206 /* likely not run as root */
1207 return 1;
1208 }
1210 struct bpf_insn prog[] = {
1211 BPF_MOV64_REG(BPF_REG_6, BPF_REG_1), /* r6 = r1 */
1212 BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol)),
1213 /* r0 = ip\->proto */
1214 BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, \-4),
1215 /* *(uint32_t *)(fp \- 4) = r0 */
1216 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), /* r2 = fp */
1217 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, \-4), /* r2 = r2 \- 4 */
1218 BPF_LD_MAP_FD(BPF_REG_1, map_fd), /* r1 = map_fd */
1219 BPF_CALL_FUNC(BPF_FUNC_map_lookup_elem),
1220 /* r0 = map_lookup(r1, r2) */
1221 BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),
1222 /* if (r0 == 0) goto pc+2 */
1223 BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */
1224 BPF_XADD(BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
1225 /* lock *(uint64_t *) r0 += r1 */
1226 .\" == atomic64_add
1227 BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
1228 BPF_EXIT_INSN(), /* return r0 */
1229 };
1231 prog_fd = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, prog,
1232 sizeof(prog) / sizeof(prog[0]), "GPL");
1234 sock = open_raw_sock("lo");
1236 assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &prog_fd,
1237 sizeof(prog_fd)) == 0);
1239 for (;;) {
1240 key = IPPROTO_TCP;
1241 assert(bpf_lookup_elem(map_fd, &key, &tcp_cnt) == 0);
1242 key = IPPROTO_UDP;
1243 assert(bpf_lookup_elem(map_fd, &key, &udp_cnt) == 0);
1244 printf("TCP %lld UDP %lld packets\en", tcp_cnt, udp_cnt);
1245 sleep(1);
1246 }
1248 return 0;
1249 }
1250 .EE
1251 .\" SRC END
1252 .PP
1253 Some complete working code can be found in the
1254 .I samples/bpf
1255 directory in the kernel source tree.
1256 .SH SEE ALSO
1257 .BR seccomp (2),
1258 .BR bpf\-helpers (7),
1259 .BR socket (7),
1260 .BR tc (8),
1261 .BR tc\-bpf (8)
1262 .PP
1263 Both classic and extended BPF are explained in the kernel source file
1264 .IR Documentation/networking/filter.txt .