1 .\" Copyright (C) 2015 Alexei Starovoitov <ast@kernel.org>
2 .\" and Copyright (C) 2015 Michael Kerrisk <mtk.manpages@gmail.com>
4 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
6 .TH BPF 2 2021-08-27 "Linux man-pages (unreleased)"
8 bpf \- perform a command on an extended BPF map or program
11 .B #include <linux/bpf.h>
13 .BI "int bpf(int " cmd ", union bpf_attr *" attr ", unsigned int " size );
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.
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
31 opcode extension provided by eBPF)
32 and access shared data structures such as eBPF maps.
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.
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
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
59 If a map lookup fails, the current program continues its execution.
61 .B BPF_MAP_TYPE_PROG_ARRAY
62 below for further details.
64 Generally, eBPF programs are loaded by the user process and automatically
65 unloaded when the process exits.
66 In some cases, for example,
68 the program will continue to stay alive inside the kernel even after the
69 process that loaded the program exits.
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
78 Each eBPF program is a set of instructions that is safe to run until
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.
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
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.
97 The same eBPF program can be attached to multiple events and different
98 eBPF programs can access the same map:
102 tracing tracing tracing packet packet packet
103 event A event B event C on eth0 on eth1 on eth2
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 |\-\-
115 The operation to be performed by the
117 system call is determined by the
120 Each operation takes an accompanying argument,
123 which is a pointer to a union of type
126 The unused fields and padding must be zeroed out before the call.
129 argument is the size of the union pointed to by
132 The value provided in
134 is one of the following:
137 Create a map and return a file descriptor that refers to the map.
138 The close-on-exec file descriptor flag (see
140 is automatically enabled for the new file descriptor.
142 .B BPF_MAP_LOOKUP_ELEM
143 Look up an element by key in a specified map and return its value.
145 .B BPF_MAP_UPDATE_ELEM
146 Create or update an element (key/value pair) in a specified map.
148 .B BPF_MAP_DELETE_ELEM
149 Look up and delete an element by key in a specified map.
151 .B BPF_MAP_GET_NEXT_KEY
152 Look up an element by key in a specified map and return the key
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
160 is automatically enabled for the new file descriptor.
164 union consists of various anonymous structures that are used by different
171 struct { /* Used by BPF_MAP_CREATE */
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
179 struct { /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
185 __aligned_u64 next_key;
190 struct { /* Used by BPF_PROG_LOAD */
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
199 uint32_t kern_version;
200 /* checked when prog_type=kprobe
202 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
204 } __attribute__((aligned(8)));
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.
213 Each map type has the following attributes:
217 maximum number of elements
223 The following wrapper functions demonstrate how various
225 commands can be used to access the maps.
226 The functions use the
228 argument to invoke different operations.
233 command creates a new map,
234 returning a new file descriptor that refers to the map.
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)
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
251 return bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
256 The new map has the type specified by
258 and attributes as specified in
263 On success, this operation returns a file descriptor.
264 On error, \-1 is returned and
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
281 and to check that the program doesn't access the map element
285 For example, when a map is created with a
287 of 8 and the eBPF program calls
291 bpf_map_lookup_elem(map_fd, fp \- 4)
295 the program will be rejected,
296 since the in-kernel helper function
300 bpf_map_lookup_elem(map_fd, void *key)
304 expects to read 8 bytes from the location pointed to by
310 is the top of the stack)
311 starting address will cause out-of-bounds stack access.
313 Similarly, when a map is created with a
315 of 1 and the eBPF program contains
319 value = bpf_map_lookup_elem(...);
320 *(uint32_t *) value = 1;
324 the program will be rejected, since it accesses the
326 pointer beyond the specified 1 byte
330 Currently, the following values are supported for
336 BPF_MAP_TYPE_UNSPEC, /* Reserve 0 as invalid map type */
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,
351 BPF_MAP_TYPE_SOCKMAP,
354 BPF_MAP_TYPE_SOCKHASH,
355 BPF_MAP_TYPE_CGROUP_STORAGE,
356 BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
357 BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
360 /* See /usr/include/linux/bpf.h for the full list. */
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
370 eBPF programs access maps with the same
371 .BR bpf_map_lookup_elem ()
373 .BR bpf_map_update_elem ()
375 Further details of the various map types are given below.
377 .B BPF_MAP_LOOKUP_ELEM
379 .B BPF_MAP_LOOKUP_ELEM
380 command looks up an element with a given
382 in the map referred to by the file descriptor
388 bpf_lookup_elem(int fd, const void *key, void *value)
390 union bpf_attr attr = {
392 .key = ptr_to_u64(key),
393 .value = ptr_to_u64(value),
396 return bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
401 If an element is found,
402 the operation returns zero and stores the element's value into
404 which must point to a buffer of
408 If no element is found, the operation returns \-1 and sets
413 .B BPF_MAP_UPDATE_ELEM
415 .B BPF_MAP_UPDATE_ELEM
417 creates or updates an element with a given
419 in the map referred to by the file descriptor
425 bpf_update_elem(int fd, const void *key, const void *value,
428 union bpf_attr attr = {
430 .key = ptr_to_u64(key),
431 .value = ptr_to_u64(value),
435 return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
442 argument should be specified as one of the following:
446 Create a new element or update an existing element.
449 Create a new element only if it did not exist.
452 Update an existing element.
455 On success, the operation returns zero.
456 On error, \-1 is returned and
465 indicates that the number of elements in the map reached the
467 limit specified at map creation time.
475 already exists in the map.
483 doesn't exist in the map.
485 .B BPF_MAP_DELETE_ELEM
487 .B BPF_MAP_DELETE_ELEM
489 deletes the element whose key is
491 from the map referred to by the file descriptor
497 bpf_delete_elem(int fd, const void *key)
499 union bpf_attr attr = {
501 .key = ptr_to_u64(key),
504 return bpf(BPF_MAP_DELETE_ELEM, &attr, sizeof(attr));
509 On success, zero is returned.
510 If the element is not found, \-1 is returned and
515 .B BPF_MAP_GET_NEXT_KEY
517 .B BPF_MAP_GET_NEXT_KEY
518 command looks up an element by
520 in the map referred to by the file descriptor
524 pointer to the key of the next element.
529 bpf_get_next_key(int fd, const void *key, void *next_key)
531 union bpf_attr attr = {
533 .key = ptr_to_u64(key),
534 .next_key = ptr_to_u64(next_key),
537 return bpf(BPF_MAP_GET_NEXT_KEY, &attr, sizeof(attr));
544 is found, the operation returns zero and sets the
546 pointer to the key of the next element.
549 is not found, the operation returns zero and sets the
551 pointer to the key of the first element.
554 is the last element, \-1 is returned and
566 This method can be used to iterate over all elements in the map.
569 Delete the map referred to by the file descriptor
571 When the user-space program that created a map exits, all maps will
572 be deleted automatically (but see NOTES).
575 The following map types are supported:
578 .\" commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475
579 Hash-table maps have the following characteristics:
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.
586 The kernel takes care of allocating and freeing key/value pairs.
589 .BR map_update_elem ()
590 helper will fail to insert new element when the
593 (This ensures that eBPF programs cannot exhaust memory.)
595 .BR map_update_elem ()
596 replaces existing elements atomically.
600 optimized for speed of lookup.
602 .B BPF_MAP_TYPE_ARRAY
603 .\" commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3
604 Array maps have the following characteristics:
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
614 are constant for the life of the eBPF program.
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.
620 All array elements pre-allocated and zero initialized at init time
622 The key is an array index, and must be exactly four bytes.
624 .BR map_delete_elem ()
627 since elements cannot be deleted.
629 .BR map_update_elem ()
630 replaces elements in a
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:
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.
645 Among the uses for array maps are the following:
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.
652 Aggregation of tracing events into a fixed set of buckets.
654 Accounting of networking events, for example, number of packets and packet
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.
665 must be exactly four bytes.
666 This map is used in conjunction with the
670 This means that an eBPF program with a program array map attached to it
671 can call from kernel side into
675 void bpf_tail_call(void *context, void *prog_map,
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.
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,
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.
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.
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.
716 char bpf_log_buf[LOG_BUF_SIZE];
719 bpf_prog_load(enum bpf_prog_type type,
720 const struct bpf_insn *insns, int insn_cnt,
723 union bpf_attr attr = {
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,
733 return bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
739 is one of the available program types:
744 BPF_PROG_TYPE_UNSPEC, /* Reserve 0 as invalid
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,
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. */
773 For further details of eBPF program types, see below.
775 The remaining fields of
785 is the number of instructions in the program referred to by
789 is a license string, which must be GPL compatible to call helper functions
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.)
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.
804 size of the buffer pointed to by
806 If the size of the buffer is not large enough to store all
807 verifier messages, \-1 is returned and
813 verbosity level of the verifier.
814 A value of zero means that the verifier will not provide a log;
817 must be a NULL pointer, and
823 to the file descriptor returned by
825 will unload the eBPF program (but see NOTES).
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.
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.
838 .SS eBPF program types
839 The eBPF program type
841 determines the subset of kernel helper functions that the program
843 The program type also determines the program input (context)\(emthe
845 .I "struct bpf_context"
846 (which is the data blob passed into the eBPF program as the first argument).
849 .\" Somewhere in this page we need a general introduction to the
850 .\" bpf_context. For example, how does a BPF program access the
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).
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.
860 The set of functions available to eBPF programs of a given type may increase
863 The following program types are supported:
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
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 */
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
889 .\" Alexei commented:
890 .\" Actually now in case of SOCKET_FILTER, SCHED_CLS, SCHED_ACT
891 .\" the program can now access skb fields.
894 .BR BPF_PROG_TYPE_KPROBE " (since Linux 4.1)"
895 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
897 .\" FIXME Document this program type
898 .\" Describe allowed helper functions for this program type
899 .\" Describe bpf_context for this program type
901 .\" FIXME We need text here to describe 'kern_version'
903 .BR BPF_PROG_TYPE_SCHED_CLS " (since Linux 4.1)"
904 .\" commit 96be4325f443dbbfeb37d2a157675ac0736531a1
905 .\" commit e2e9b6541dd4b31848079da80fe2253daaafb549
907 .\" FIXME Document this program type
908 .\" Describe allowed helper functions for this program type
909 .\" Describe bpf_context for this program type
911 .BR BPF_PROG_TYPE_SCHED_ACT " (since Linux 4.1)"
912 .\" commit 94caee8c312d96522bcdae88791aaa9ebcd5f22c
913 .\" commit a8cb5f556b567974d75ea29c15181c445c541b1f
915 .\" FIXME Document this program type
916 .\" Describe allowed helper functions for this program type
917 .\" Describe bpf_context for this program type
919 Once a program is loaded, it can be attached to an event.
920 Various kernel subsystems have different ways to do so.
923 .\" commit 89aa075832b0da4402acebd698d0411dcc82d03e
924 the following call will attach the program
928 which was created by an earlier call to
933 setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_BPF,
934 &prog_fd, sizeof(prog_fd));
939 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
940 the following call may be used to attach
941 the eBPF program referred to by the file descriptor
943 to a perf event file descriptor,
945 that was created by a previous call to
946 .BR perf_event_open (2):
950 ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
956 For a successful call, the return value depends on the operation:
959 The new file descriptor associated with the eBPF map.
962 The new file descriptor associated with the eBPF program.
967 On error, \-1 is returned, and
969 is set to indicate the error.
973 The eBPF program is too large or a map reached the
975 limit (maximum number of elements).
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
992 for the specific reason provided by the verifier.
996 is not an open file descriptor.
1007 is outside the accessible address space.
1010 The value specified in
1012 is not recognized by this kernel.
1016 .BR BPF_MAP_CREATE ,
1019 or attributes are invalid.
1025 some of the fields of
1027 that are not used by this command
1028 are not set to zero.
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.
1040 .B BPF_MAP_LOOKUP_ELEM
1042 .BR BPF_MAP_DELETE_ELEM ,
1043 indicates that the element with the given
1048 Cannot allocate sufficient memory.
1051 The call was made without sufficient privilege
1058 system call first appeared in Linux 3.18.
1062 system call is Linux-specific.
1064 Prior to Linux 4.4, all
1066 commands require the caller to have the
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().
1082 get_smp_processor_id
1089 Unprivileged access may be blocked by writing the value 1 to the file
1090 .IR /proc/sys/kernel/unprivileged_bpf_disabled .
1092 eBPF objects (maps and programs) can be shared between processes.
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
1102 An eBPF object is deallocated only after all file descriptors
1103 referring to the object have been closed.
1105 eBPF programs can be written in a restricted C that is compiled (using the
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
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 :
1125 Disable JIT compilation (default).
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.
1136 .\" commit 290af86629b25ffd1ed6232c4e9107da031705cb
1137 the kernel may configured with the
1138 .B CONFIG_BPF_JIT_ALWAYS_ON
1140 In this case, the JIT compiler is always enabled, and the
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.)
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:
1152 x86-64 (since Linux 3.18; cBPF since Linux 3.0);
1153 .\" commit 0a14842f5a3c0e88a1e59fac5c3025db39721f74
1156 ARM32 (since Linux 3.18; cBPF since Linux 3.4);
1157 .\" commit ddecdfcea0ae891f782ae853771c867ab51024c2
1159 SPARC 32 (since Linux 3.18; cBPF since Linux 3.5);
1160 .\" commit 2809a2087cc44b55e4377d7b9be3f7f5d2569091
1162 ARM-64 (since Linux 3.18);
1163 .\" commit e54bcde3d69d40023ae77727213d14f920eb264a
1165 s390 (since Linux 4.1; cBPF since Linux 3.7);
1166 .\" commit c10302efe569bfd646b4c22df29577a4595b4580
1168 PowerPC 64 (since Linux 4.8; cBPF since Linux 3.1);
1169 .\" commit 0ca87f05ba8bdc6791c14878464efc901ad71e99
1170 .\" commit 156d0e290e969caba25f1851c52417c14d141b24
1172 SPARC 64 (since Linux 4.12);
1173 .\" commit 7a12b5031c6b947cc13918237ae652b536243b76
1175 x86-32 (since Linux 4.18);
1176 .\" commit 03f5781be2c7b7e728d724ac70ba10799cc710d7
1178 MIPS 64 (since Linux 4.18; cBPF since Linux 3.16);
1179 .\" commit c6610de353da5ca6eee5b8960e838a87a90ead0c
1180 .\" commit f381bf6d82f032b7410185b35d000ea370ac706b
1182 riscv (since Linux 5.1).
1183 .\" commit 2353ecc6f91fd15b893fa01bf85a1c7a823ee4f2
1186 .\" [[FIXME]] SRC BEGIN (bpf.c)
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)]
1193 * 3. attach prog_fd to raw socket via setsockopt()
1194 * 4. print number of received TCP/UDP packets every second
1197 main(int argc, char *argv[])
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);
1205 printf("failed to create map \(aq%s\(aq\en", strerror(errno));
1206 /* likely not run as root */
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 */
1227 BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
1228 BPF_EXIT_INSN(), /* return r0 */
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);
1241 assert(bpf_lookup_elem(map_fd, &key, &tcp_cnt) == 0);
1243 assert(bpf_lookup_elem(map_fd, &key, &udp_cnt) == 0);
1244 printf("TCP %lld UDP %lld packets\en", tcp_cnt, udp_cnt);
1253 Some complete working code can be found in the
1255 directory in the kernel source tree.
1258 .BR bpf\-helpers (7),
1263 Both classic and extended BPF are explained in the kernel source file
1264 .IR Documentation/networking/filter.txt .