1 .\" Copyright (C) 2015 Alexei Starovoitov <ast@kernel.org>
2 .\" and Copyright (C) 2015 Michael Kerrisk <mtk.manpages@gmail.com>
4 .\" %%%LICENSE_START(VERBATIM)
5 .\" Permission is granted to make and distribute verbatim copies of this
6 .\" manual provided the copyright notice and this permission notice are
7 .\" preserved on all copies.
9 .\" Permission is granted to copy and distribute modified versions of this
10 .\" manual under the conditions for verbatim copying, provided that the
11 .\" entire resulting derived work is distributed under the terms of a
12 .\" permission notice identical to this one.
14 .\" Since the Linux kernel and libraries are constantly changing, this
15 .\" manual page may be incorrect or out-of-date. The author(s) assume no
16 .\" responsibility for errors or omissions, or for damages resulting from
17 .\" the use of the information contained herein. The author(s) may not
18 .\" have taken the same level of care in the production of this manual,
19 .\" which is licensed free of charge, as they might when working
22 .\" Formatted or processed versions of this manual, if unaccompanied by
23 .\" the source, must acknowledge the copyright and authors of this work.
26 .TH BPF 2 2021-03-22 "Linux" "Linux Programmer's Manual"
28 bpf \- perform a command on an extended BPF map or program
31 .B #include <linux/bpf.h>
33 .BI "int bpf(int " cmd ", union bpf_attr *" attr ", unsigned int " size );
38 system call performs a range of operations related to extended
39 Berkeley Packet Filters.
40 Extended BPF (or eBPF) is similar to
41 the original ("classic") BPF (cBPF) used to filter network packets.
42 For both cBPF and eBPF programs,
43 the kernel statically analyzes the programs before loading them,
44 in order to ensure that they cannot harm the running system.
46 eBPF extends cBPF in multiple ways, including the ability to call
47 a fixed set of in-kernel helper functions
48 .\" See 'enum bpf_func_id' in include/uapi/linux/bpf.h
51 opcode extension provided by eBPF)
52 and access shared data structures such as eBPF maps.
54 .SS Extended BPF Design/Architecture
55 eBPF maps are a generic data structure for storage of different data types.
56 Data types are generally treated as binary blobs, so a user just specifies
57 the size of the key and the size of the value at map-creation time.
58 In other words, a key/value for a given map can have an arbitrary structure.
60 A user process can create multiple maps (with key/value-pairs being
61 opaque bytes of data) and access them via file descriptors.
62 Different eBPF programs can access the same maps in parallel.
63 It's up to the user process and eBPF program to decide what they store
66 There's one special map type, called a program array.
67 This type of map stores file descriptors referring to other eBPF programs.
68 When a lookup in the map is performed, the program flow is
69 redirected in-place to the beginning of another eBPF program and does not
70 return back to the calling program.
71 The level of nesting has a fixed limit of 32,
72 .\" Defined by the kernel constant MAX_TAIL_CALL_CNT in include/linux/bpf.h
73 so that infinite loops cannot be crafted.
74 At run time, the program file descriptors stored in the map can be modified,
75 so program functionality can be altered based on specific requirements.
76 All programs referred to in a program-array map must
77 have been previously loaded into the kernel via
79 If a map lookup fails, the current program continues its execution.
81 .B BPF_MAP_TYPE_PROG_ARRAY
82 below for further details.
84 Generally, eBPF programs are loaded by the user process and automatically
85 unloaded when the process exits.
86 In some cases, for example,
88 the program will continue to stay alive inside the kernel even after the
89 process that loaded the program exits.
91 the tc subsystem holds a reference to the eBPF program after the
92 file descriptor has been closed by the user-space program.
93 Thus, whether a specific program continues to live inside the kernel
94 depends on how it is further attached to a given kernel subsystem
95 after it was loaded via
98 Each eBPF program is a set of instructions that is safe to run until
100 An in-kernel verifier statically determines that the eBPF program
101 terminates and is safe to execute.
102 During verification, the kernel increments reference counts for each of
103 the maps that the eBPF program uses,
104 so that the attached maps can't be removed until the program is unloaded.
106 eBPF programs can be attached to different events.
107 These events can be the arrival of network packets, tracing
108 events, classification events by network queueing disciplines
109 (for eBPF programs attached to a
111 classifier), and other types that may be added in the future.
112 A new event triggers execution of the eBPF program, which
113 may store information about the event in eBPF maps.
114 Beyond storing data, eBPF programs may call a fixed set of
115 in-kernel helper functions.
117 The same eBPF program can be attached to multiple events and different
118 eBPF programs can access the same map:
122 tracing tracing tracing packet packet packet
123 event A event B event C on eth0 on eth1 on eth2
126 \-\-> tracing <\-\- tracing socket tc ingress tc egress
127 prog_1 prog_2 prog_3 classifier action
128 | | | | prog_4 prog_5
129 |\-\-\- \-\-\-\-\-| |\-\-\-\-\-\-| map_3 | |
130 map_1 map_2 \-\-| map_4 |\-\-
135 The operation to be performed by the
137 system call is determined by the
140 Each operation takes an accompanying argument,
143 which is a pointer to a union of type
148 argument is the size of the union pointed to by
151 The value provided in
153 is one of the following:
156 Create a map and return a file descriptor that refers to the map.
157 The close-on-exec file descriptor flag (see
159 is automatically enabled for the new file descriptor.
161 .B BPF_MAP_LOOKUP_ELEM
162 Look up an element by key in a specified map and return its value.
164 .B BPF_MAP_UPDATE_ELEM
165 Create or update an element (key/value pair) in a specified map.
167 .B BPF_MAP_DELETE_ELEM
168 Look up and delete an element by key in a specified map.
170 .B BPF_MAP_GET_NEXT_KEY
171 Look up an element by key in a specified map and return the key
175 Verify and load an eBPF program,
176 returning a new file descriptor associated with the program.
177 The close-on-exec file descriptor flag (see
179 is automatically enabled for the new file descriptor.
183 union consists of various anonymous structures that are used by different
190 struct { /* Used by BPF_MAP_CREATE */
192 __u32 key_size; /* size of key in bytes */
193 __u32 value_size; /* size of value in bytes */
194 __u32 max_entries; /* maximum number of entries
198 struct { /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
204 __aligned_u64 next_key;
209 struct { /* Used by BPF_PROG_LOAD */
212 __aligned_u64 insns; /* \(aqconst struct bpf_insn *\(aq */
213 __aligned_u64 license; /* \(aqconst char *\(aq */
214 __u32 log_level; /* verbosity level of verifier */
215 __u32 log_size; /* size of user buffer */
216 __aligned_u64 log_buf; /* user supplied \(aqchar *\(aq
219 /* checked when prog_type=kprobe
221 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
223 } __attribute__((aligned(8)));
228 Maps are a generic data structure for storage of different types of data.
229 They allow sharing of data between eBPF kernel programs,
230 and also between kernel and user-space applications.
232 Each map type has the following attributes:
236 maximum number of elements
242 The following wrapper functions demonstrate how various
244 commands can be used to access the maps.
245 The functions use the
247 argument to invoke different operations.
252 command creates a new map,
253 returning a new file descriptor that refers to the map.
258 bpf_create_map(enum bpf_map_type map_type,
259 unsigned int key_size,
260 unsigned int value_size,
261 unsigned int max_entries)
263 union bpf_attr attr = {
264 .map_type = map_type,
265 .key_size = key_size,
266 .value_size = value_size,
267 .max_entries = max_entries
270 return bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
275 The new map has the type specified by
277 and attributes as specified in
282 On success, this operation returns a file descriptor.
283 On error, \-1 is returned and
295 attributes will be used by the verifier during program loading
296 to check that the program is calling
297 .BR bpf_map_*_elem ()
298 helper functions with a correctly initialized
300 and to check that the program doesn't access the map element
304 For example, when a map is created with a
306 of 8 and the eBPF program calls
310 bpf_map_lookup_elem(map_fd, fp \- 4)
314 the program will be rejected,
315 since the in-kernel helper function
319 bpf_map_lookup_elem(map_fd, void *key)
323 expects to read 8 bytes from the location pointed to by
329 is the top of the stack)
330 starting address will cause out-of-bounds stack access.
332 Similarly, when a map is created with a
334 of 1 and the eBPF program contains
338 value = bpf_map_lookup_elem(...);
343 the program will be rejected, since it accesses the
345 pointer beyond the specified 1 byte
349 Currently, the following values are supported for
355 BPF_MAP_TYPE_UNSPEC, /* Reserve 0 as invalid map type */
358 BPF_MAP_TYPE_PROG_ARRAY,
359 BPF_MAP_TYPE_PERF_EVENT_ARRAY,
360 BPF_MAP_TYPE_PERCPU_HASH,
361 BPF_MAP_TYPE_PERCPU_ARRAY,
362 BPF_MAP_TYPE_STACK_TRACE,
363 BPF_MAP_TYPE_CGROUP_ARRAY,
364 BPF_MAP_TYPE_LRU_HASH,
365 BPF_MAP_TYPE_LRU_PERCPU_HASH,
366 BPF_MAP_TYPE_LPM_TRIE,
367 BPF_MAP_TYPE_ARRAY_OF_MAPS,
368 BPF_MAP_TYPE_HASH_OF_MAPS,
370 BPF_MAP_TYPE_SOCKMAP,
373 BPF_MAP_TYPE_SOCKHASH,
374 BPF_MAP_TYPE_CGROUP_STORAGE,
375 BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
376 BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
379 /* See /usr/include/linux/bpf.h for the full list. */
385 selects one of the available map implementations in the kernel.
386 .\" FIXME We need an explanation of why one might choose each of
387 .\" these map implementations
389 eBPF programs access maps with the same
390 .BR bpf_map_lookup_elem ()
392 .BR bpf_map_update_elem ()
394 Further details of the various map types are given below.
396 .B BPF_MAP_LOOKUP_ELEM
398 .B BPF_MAP_LOOKUP_ELEM
399 command looks up an element with a given
401 in the map referred to by the file descriptor
407 bpf_lookup_elem(int fd, const void *key, void *value)
409 union bpf_attr attr = {
411 .key = ptr_to_u64(key),
412 .value = ptr_to_u64(value),
415 return bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
420 If an element is found,
421 the operation returns zero and stores the element's value into
423 which must point to a buffer of
427 If no element is found, the operation returns \-1 and sets
432 .B BPF_MAP_UPDATE_ELEM
434 .B BPF_MAP_UPDATE_ELEM
436 creates or updates an element with a given
438 in the map referred to by the file descriptor
444 bpf_update_elem(int fd, const void *key, const void *value,
447 union bpf_attr attr = {
449 .key = ptr_to_u64(key),
450 .value = ptr_to_u64(value),
454 return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
461 argument should be specified as one of the following:
465 Create a new element or update an existing element.
468 Create a new element only if it did not exist.
471 Update an existing element.
474 On success, the operation returns zero.
475 On error, \-1 is returned and
484 indicates that the number of elements in the map reached the
486 limit specified at map creation time.
494 already exists in the map.
502 doesn't exist in the map.
504 .B BPF_MAP_DELETE_ELEM
506 .B BPF_MAP_DELETE_ELEM
508 deletes the element whose key is
510 from the map referred to by the file descriptor
516 bpf_delete_elem(int fd, const void *key)
518 union bpf_attr attr = {
520 .key = ptr_to_u64(key),
523 return bpf(BPF_MAP_DELETE_ELEM, &attr, sizeof(attr));
528 On success, zero is returned.
529 If the element is not found, \-1 is returned and
534 .B BPF_MAP_GET_NEXT_KEY
536 .B BPF_MAP_GET_NEXT_KEY
537 command looks up an element by
539 in the map referred to by the file descriptor
543 pointer to the key of the next element.
548 bpf_get_next_key(int fd, const void *key, void *next_key)
550 union bpf_attr attr = {
552 .key = ptr_to_u64(key),
553 .next_key = ptr_to_u64(next_key),
556 return bpf(BPF_MAP_GET_NEXT_KEY, &attr, sizeof(attr));
563 is found, the operation returns zero and sets the
565 pointer to the key of the next element.
568 is not found, the operation returns zero and sets the
570 pointer to the key of the first element.
573 is the last element, \-1 is returned and
585 This method can be used to iterate over all elements in the map.
588 Delete the map referred to by the file descriptor
590 When the user-space program that created a map exits, all maps will
591 be deleted automatically (but see NOTES).
594 The following map types are supported:
597 .\" commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475
598 Hash-table maps have the following characteristics:
601 Maps are created and destroyed by user-space programs.
602 Both user-space and eBPF programs
603 can perform lookup, update, and delete operations.
605 The kernel takes care of allocating and freeing key/value pairs.
608 .BR map_update_elem ()
609 helper will fail to insert new element when the
612 (This ensures that eBPF programs cannot exhaust memory.)
614 .BR map_update_elem ()
615 replaces existing elements atomically.
619 optimized for speed of lookup.
621 .B BPF_MAP_TYPE_ARRAY
622 .\" commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3
623 Array maps have the following characteristics:
626 Optimized for fastest possible lookup.
627 In the future the verifier/JIT compiler
628 may recognize lookup() operations that employ a constant key
629 and optimize it into constant pointer.
630 It is possible to optimize a non-constant
631 key into direct pointer arithmetic as well, since pointers and
633 are constant for the life of the eBPF program.
635 .BR array_map_lookup_elem ()
636 may be 'inlined' by the verifier/JIT compiler
637 while preserving concurrent access to this map from user space.
639 All array elements pre-allocated and zero initialized at init time
641 The key is an array index, and must be exactly four bytes.
643 .BR map_delete_elem ()
646 since elements cannot be deleted.
648 .BR map_update_elem ()
649 replaces elements in a
652 for atomic updates, a hash-table map should be used instead.
653 There is however one special case that can also be used with arrays:
655 .B __sync_fetch_and_add()
656 can be used on 32 and 64 bit atomic counters.
657 For example, it can be
658 applied on the whole value itself if it represents a single counter,
659 or in case of a structure containing multiple counters, it could be
660 used on individual counters.
661 This is quite often useful for aggregation and accounting of events.
664 Among the uses for array maps are the following:
667 As "global" eBPF variables: an array of 1 element whose key is (index) 0
668 and where the value is a collection of 'global' variables which
669 eBPF programs can use to keep state between events.
671 Aggregation of tracing events into a fixed set of buckets.
673 Accounting of networking events, for example, number of packets and packet
677 .BR BPF_MAP_TYPE_PROG_ARRAY " (since Linux 4.2)"
678 A program array map is a special kind of array map whose map values
679 contain only file descriptors referring to other eBPF programs.
684 must be exactly four bytes.
685 This map is used in conjunction with the
689 This means that an eBPF program with a program array map attached to it
690 can call from kernel side into
694 void bpf_tail_call(void *context, void *prog_map,
699 and therefore replace its own program flow with the one from the program
700 at the given program array slot, if present.
701 This can be regarded as kind of a jump table to a different eBPF program.
702 The invoked program will then reuse the same stack.
703 When a jump into the new program has been performed,
704 it won't return to the old program anymore.
706 If no eBPF program is found at the given index of the program array
707 (because the map slot doesn't contain a valid program file descriptor,
708 the specified lookup index/key is out of bounds,
710 .\" MAX_TAIL_CALL_CNT
711 nested calls has been exceed),
712 execution continues with the current eBPF program.
713 This can be used as a fall-through for default cases.
715 A program array map is useful, for example, in tracing or networking, to
716 handle individual system calls or protocols in their own subprograms and
717 use their identifiers as an individual map index.
718 This approach may result in performance benefits,
719 and also makes it possible to overcome the maximum
720 instruction limit of a single eBPF program.
721 In dynamic environments,
722 a user-space daemon might atomically replace individual subprograms
723 at run-time with newer versions to alter overall program behavior,
724 for instance, if global policies change.
729 command is used to load an eBPF program into the kernel.
730 The return value for this command is a new file descriptor associated
731 with this eBPF program.
735 char bpf_log_buf[LOG_BUF_SIZE];
738 bpf_prog_load(enum bpf_prog_type type,
739 const struct bpf_insn *insns, int insn_cnt,
742 union bpf_attr attr = {
744 .insns = ptr_to_u64(insns),
745 .insn_cnt = insn_cnt,
746 .license = ptr_to_u64(license),
747 .log_buf = ptr_to_u64(bpf_log_buf),
748 .log_size = LOG_BUF_SIZE,
752 return bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
758 is one of the available program types:
763 BPF_PROG_TYPE_UNSPEC, /* Reserve 0 as invalid
765 BPF_PROG_TYPE_SOCKET_FILTER,
766 BPF_PROG_TYPE_KPROBE,
767 BPF_PROG_TYPE_SCHED_CLS,
768 BPF_PROG_TYPE_SCHED_ACT,
769 BPF_PROG_TYPE_TRACEPOINT,
771 BPF_PROG_TYPE_PERF_EVENT,
772 BPF_PROG_TYPE_CGROUP_SKB,
773 BPF_PROG_TYPE_CGROUP_SOCK,
774 BPF_PROG_TYPE_LWT_IN,
775 BPF_PROG_TYPE_LWT_OUT,
776 BPF_PROG_TYPE_LWT_XMIT,
777 BPF_PROG_TYPE_SOCK_OPS,
778 BPF_PROG_TYPE_SK_SKB,
779 BPF_PROG_TYPE_CGROUP_DEVICE,
780 BPF_PROG_TYPE_SK_MSG,
781 BPF_PROG_TYPE_RAW_TRACEPOINT,
782 BPF_PROG_TYPE_CGROUP_SOCK_ADDR,
783 BPF_PROG_TYPE_LWT_SEG6LOCAL,
784 BPF_PROG_TYPE_LIRC_MODE2,
785 BPF_PROG_TYPE_SK_REUSEPORT,
786 BPF_PROG_TYPE_FLOW_DISSECTOR,
787 /* See /usr/include/linux/bpf.h for the full list. */
792 For further details of eBPF program types, see below.
794 The remaining fields of
804 is the number of instructions in the program referred to by
808 is a license string, which must be GPL compatible to call helper functions
811 (The licensing rules are the same as for kernel modules,
812 so that also dual licenses, such as "Dual BSD/GPL", may be used.)
815 is a pointer to a caller-allocated buffer in which the in-kernel
816 verifier can store the verification log.
817 This log is a multi-line string that can be checked by
818 the program author in order to understand how the verifier came to
819 the conclusion that the eBPF program is unsafe.
820 The format of the output can change at any time as the verifier evolves.
823 size of the buffer pointed to by
825 If the size of the buffer is not large enough to store all
826 verifier messages, \-1 is returned and
832 verbosity level of the verifier.
833 A value of zero means that the verifier will not provide a log;
836 must be a NULL pointer, and
842 to the file descriptor returned by
844 will unload the eBPF program (but see NOTES).
846 Maps are accessible from eBPF programs and are used to exchange data between
847 eBPF programs and between eBPF programs and user-space programs.
849 eBPF programs can process various events (like kprobe, packets) and
850 store their data into a map,
851 and user-space programs can then fetch data from the map.
852 Conversely, user-space programs can use a map as a configuration mechanism,
853 populating the map with values checked by the eBPF program,
854 which then modifies its behavior on the fly according to those values.
857 .SS eBPF program types
858 The eBPF program type
860 determines the subset of kernel helper functions that the program
862 The program type also determines the program input (context)\(emthe
864 .I "struct bpf_context"
865 (which is the data blob passed into the eBPF program as the first argument).
868 .\" Somewhere in this page we need a general introduction to the
869 .\" bpf_context. For example, how does a BPF program access the
872 For example, a tracing program does not have the exact same
873 subset of helper functions as a socket filter program
874 (though they may have some helpers in common).
876 the input (context) for a tracing program is a set of register values,
877 while for a socket filter it is a network packet.
879 The set of functions available to eBPF programs of a given type may increase
882 The following program types are supported:
884 .BR BPF_PROG_TYPE_SOCKET_FILTER " (since Linux 3.19)"
885 Currently, the set of functions for
886 .B BPF_PROG_TYPE_SOCKET_FILTER
891 bpf_map_lookup_elem(map_fd, void *key)
892 /* look up key in a map_fd */
893 bpf_map_update_elem(map_fd, void *key, void *value)
894 /* update key/value */
895 bpf_map_delete_elem(map_fd, void *key)
896 /* delete key in a map_fd */
902 argument is a pointer to a
903 .IR "struct __sk_buff" .
904 .\" FIXME: We need some text here to explain how the program
905 .\" accesses __sk_buff.
906 .\" See 'struct __sk_buff' and commit 9bac3d6d548e5
908 .\" Alexei commented:
909 .\" Actually now in case of SOCKET_FILTER, SCHED_CLS, SCHED_ACT
910 .\" the program can now access skb fields.
913 .BR BPF_PROG_TYPE_KPROBE " (since Linux 4.1)"
914 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
916 .\" FIXME Document this program type
917 .\" Describe allowed helper functions for this program type
918 .\" Describe bpf_context for this program type
920 .\" FIXME We need text here to describe 'kern_version'
922 .BR BPF_PROG_TYPE_SCHED_CLS " (since Linux 4.1)"
923 .\" commit 96be4325f443dbbfeb37d2a157675ac0736531a1
924 .\" commit e2e9b6541dd4b31848079da80fe2253daaafb549
926 .\" FIXME Document this program type
927 .\" Describe allowed helper functions for this program type
928 .\" Describe bpf_context for this program type
930 .BR BPF_PROG_TYPE_SCHED_ACT " (since Linux 4.1)"
931 .\" commit 94caee8c312d96522bcdae88791aaa9ebcd5f22c
932 .\" commit a8cb5f556b567974d75ea29c15181c445c541b1f
934 .\" FIXME Document this program type
935 .\" Describe allowed helper functions for this program type
936 .\" Describe bpf_context for this program type
938 Once a program is loaded, it can be attached to an event.
939 Various kernel subsystems have different ways to do so.
942 .\" commit 89aa075832b0da4402acebd698d0411dcc82d03e
943 the following call will attach the program
947 which was created by an earlier call to
952 setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_BPF,
953 &prog_fd, sizeof(prog_fd));
958 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
959 the following call may be used to attach
960 the eBPF program referred to by the file descriptor
962 to a perf event file descriptor,
964 that was created by a previous call to
965 .BR perf_event_open (2):
969 ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
975 For a successful call, the return value depends on the operation:
978 The new file descriptor associated with the eBPF map.
981 The new file descriptor associated with the eBPF program.
986 On error, \-1 is returned, and
988 is set to indicate the error.
992 The eBPF program is too large or a map reached the
994 limit (maximum number of elements).
999 even though all program instructions are valid, the program has been
1000 rejected because it was deemed unsafe.
1001 This may be because it may have
1002 accessed a disallowed memory region or an uninitialized stack/register or
1003 because the function constraints don't match the actual types or because
1004 there was a misaligned memory access.
1005 In this case, it is recommended to call
1011 for the specific reason provided by the verifier.
1015 is not an open file descriptor.
1026 is outside the accessible address space.
1029 The value specified in
1031 is not recognized by this kernel.
1035 .BR BPF_MAP_CREATE ,
1038 or attributes are invalid.
1044 some of the fields of
1046 that are not used by this command
1047 are not set to zero.
1052 indicates an attempt to load an invalid program.
1053 eBPF programs can be deemed
1054 invalid due to unrecognized instructions, the use of reserved fields, jumps
1055 out of range, infinite loops or calls of unknown functions.
1059 .B BPF_MAP_LOOKUP_ELEM
1061 .BR BPF_MAP_DELETE_ELEM ,
1062 indicates that the element with the given
1067 Cannot allocate sufficient memory.
1070 The call was made without sufficient privilege
1077 system call first appeared in Linux 3.18.
1081 system call is Linux-specific.
1083 Prior to Linux 4.4, all
1085 commands require the caller to have the
1088 From Linux 4.4 onwards,
1089 .\" commit 1be7f75d1668d6296b80bf35dcf6762393530afc
1090 an unprivileged user may create limited programs of type
1091 .BR BPF_PROG_TYPE_SOCKET_FILTER
1092 and associated maps.
1093 However they may not store kernel pointers within
1094 the maps and are presently limited to the following helper functions:
1095 .\" [Linux 5.6] mtk: The list of available functions is, I think, governed
1096 .\" by the check in net/core/filter.c::bpf_base_func_proto().
1101 get_smp_processor_id
1108 Unprivileged access may be blocked by writing the value 1 to the file
1109 .IR /proc/sys/kernel/unprivileged_bpf_disabled .
1111 eBPF objects (maps and programs) can be shared between processes.
1114 the child inherits file descriptors referring to the same eBPF objects.
1115 In addition, file descriptors referring to eBPF objects can be
1116 transferred over UNIX domain sockets.
1117 File descriptors referring to eBPF objects can be duplicated
1118 in the usual way, using
1121 An eBPF object is deallocated only after all file descriptors
1122 referring to the object have been closed.
1124 eBPF programs can be written in a restricted C that is compiled (using the
1126 compiler) into eBPF bytecode.
1127 Various features are omitted from this restricted C, such as loops,
1128 global variables, variadic functions, floating-point numbers,
1129 and passing structures as function arguments.
1130 Some examples can be found in the
1131 .I samples/bpf/*_kern.c
1132 files in the kernel source tree.
1133 .\" There are also examples for the tc classifier, in the iproute2
1134 .\" project, in examples/bpf
1136 The kernel contains a just-in-time (JIT) compiler that translates
1137 eBPF bytecode into native machine code for better performance.
1138 In kernels before Linux 4.15,
1139 the JIT compiler is disabled by default,
1140 but its operation can be controlled by writing one of the
1141 following integer strings to the file
1142 .IR /proc/sys/net/core/bpf_jit_enable :
1144 Disable JIT compilation (default).
1149 The generated opcodes are dumped in hexadecimal into the kernel log.
1150 These opcodes can then be disassembled using the program
1151 .I tools/net/bpf_jit_disasm.c
1152 provided in the kernel source tree.
1155 .\" commit 290af86629b25ffd1ed6232c4e9107da031705cb
1156 the kernel may configured with the
1157 .B CONFIG_BPF_JIT_ALWAYS_ON
1159 In this case, the JIT compiler is always enabled, and the
1161 is initialized to 1 and is immutable.
1162 (This kernel configuration option was provided as a mitigation for
1163 one of the Spectre attacks against the BPF interpreter.)
1165 The JIT compiler for eBPF is currently
1166 .\" Last reviewed in Linux 4.18-rc by grepping for BPF_ALU64 in arch/
1167 .\" and by checking the documentation for bpf_jit_enable in
1168 .\" Documentation/sysctl/net.txt
1169 available for the following architectures:
1171 x86-64 (since Linux 3.18; cBPF since Linux 3.0);
1172 .\" commit 0a14842f5a3c0e88a1e59fac5c3025db39721f74
1175 ARM32 (since Linux 3.18; cBPF since Linux 3.4);
1176 .\" commit ddecdfcea0ae891f782ae853771c867ab51024c2
1178 SPARC 32 (since Linux 3.18; cBPF since Linux 3.5);
1179 .\" commit 2809a2087cc44b55e4377d7b9be3f7f5d2569091
1181 ARM-64 (since Linux 3.18);
1182 .\" commit e54bcde3d69d40023ae77727213d14f920eb264a
1184 s390 (since Linux 4.1; cBPF since Linux 3.7);
1185 .\" commit c10302efe569bfd646b4c22df29577a4595b4580
1187 PowerPC 64 (since Linux 4.8; cBPF since Linux 3.1);
1188 .\" commit 0ca87f05ba8bdc6791c14878464efc901ad71e99
1189 .\" commit 156d0e290e969caba25f1851c52417c14d141b24
1191 SPARC 64 (since Linux 4.12);
1192 .\" commit 7a12b5031c6b947cc13918237ae652b536243b76
1194 x86-32 (since Linux 4.18);
1195 .\" commit 03f5781be2c7b7e728d724ac70ba10799cc710d7
1197 MIPS 64 (since Linux 4.18; cBPF since Linux 3.16);
1198 .\" commit c6610de353da5ca6eee5b8960e838a87a90ead0c
1199 .\" commit f381bf6d82f032b7410185b35d000ea370ac706b
1201 riscv (since Linux 5.1).
1202 .\" commit 2353ecc6f91fd15b893fa01bf85a1c7a823ee4f2
1206 /* bpf+sockets example:
1207 * 1. create array map of 256 elements
1208 * 2. load program that counts number of packets received
1209 * r0 = skb\->data[ETH_HLEN + offsetof(struct iphdr, protocol)]
1211 * 3. attach prog_fd to raw socket via setsockopt()
1212 * 4. print number of received TCP/UDP packets every second
1215 main(int argc, char *argv[])
1217 int sock, map_fd, prog_fd, key;
1218 long long value = 0, tcp_cnt, udp_cnt;
1220 map_fd = bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(key),
1221 sizeof(value), 256);
1223 printf("failed to create map \(aq%s\(aq\en", strerror(errno));
1224 /* likely not run as root */
1228 struct bpf_insn prog[] = {
1229 BPF_MOV64_REG(BPF_REG_6, BPF_REG_1), /* r6 = r1 */
1230 BPF_LD_ABS(BPF_B, ETH_HLEN + offsetof(struct iphdr, protocol)),
1231 /* r0 = ip\->proto */
1232 BPF_STX_MEM(BPF_W, BPF_REG_10, BPF_REG_0, \-4),
1233 /* *(u32 *)(fp \- 4) = r0 */
1234 BPF_MOV64_REG(BPF_REG_2, BPF_REG_10), /* r2 = fp */
1235 BPF_ALU64_IMM(BPF_ADD, BPF_REG_2, \-4), /* r2 = r2 \- 4 */
1236 BPF_LD_MAP_FD(BPF_REG_1, map_fd), /* r1 = map_fd */
1237 BPF_CALL_FUNC(BPF_FUNC_map_lookup_elem),
1238 /* r0 = map_lookup(r1, r2) */
1239 BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 2),
1240 /* if (r0 == 0) goto pc+2 */
1241 BPF_MOV64_IMM(BPF_REG_1, 1), /* r1 = 1 */
1242 BPF_XADD(BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
1243 /* lock *(u64 *) r0 += r1 */
1245 BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
1246 BPF_EXIT_INSN(), /* return r0 */
1249 prog_fd = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, prog,
1250 sizeof(prog) / sizeof(prog[0]), "GPL");
1252 sock = open_raw_sock("lo");
1254 assert(setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &prog_fd,
1255 sizeof(prog_fd)) == 0);
1259 assert(bpf_lookup_elem(map_fd, &key, &tcp_cnt) == 0);
1261 assert(bpf_lookup_elem(map_fd, &key, &udp_cnt) == 0);
1262 printf("TCP %lld UDP %lld packets\en", tcp_cnt, udp_cnt);
1270 Some complete working code can be found in the
1272 directory in the kernel source tree.
1275 .BR bpf\-helpers (7),
1280 Both classic and extended BPF are explained in the kernel source file
1281 .IR Documentation/networking/filter.txt .