| blob | 246053201c2bb1b86670acb721384c9b529489df |
1 .\" Copyright (C) 2015 Alexei Starovoitov <ast@kernel.org>
2 .\" and Copyright (C) 2015 Michael Kerrisk <mtk.manpages@gmail.com>
3 .\"
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.
8 .\"
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.
13 .\"
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
20 .\" professionally.
21 .\"
22 .\" Formatted or processed versions of this manual, if unaccompanied by
23 .\" the source, must acknowledge the copyright and authors of this work.
24 .\" %%%LICENSE_END
25 .\"
26 .TH BPF 2 2021-03-22 "Linux" "Linux Programmer's Manual"
27 .SH NAME
28 bpf \- perform a command on an extended BPF map or program
29 .SH SYNOPSIS
30 .nf
31 .B #include <linux/bpf.h>
32 .PP
33 .BI "int bpf(int " cmd ", union bpf_attr *" attr ", unsigned int " size );
34 .fi
35 .SH DESCRIPTION
36 The
37 .BR bpf ()
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.
45 .PP
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
49 (via the
50 .B BPF_CALL
51 opcode extension provided by eBPF)
52 and access shared data structures such as eBPF maps.
53 .\"
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.
59 .PP
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
64 inside maps.
65 .PP
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
78 .BR bpf ().
79 If a map lookup fails, the current program continues its execution.
80 See
81 .B BPF_MAP_TYPE_PROG_ARRAY
82 below for further details.
83 .PP
84 Generally, eBPF programs are loaded by the user process and automatically
85 unloaded when the process exits.
86 In some cases, for example,
87 .BR tc\-bpf (8),
88 the program will continue to stay alive inside the kernel even after the
89 process that loaded the program exits.
90 In that case,
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
96 .BR bpf ().
97 .PP
98 Each eBPF program is a set of instructions that is safe to run until
99 its completion.
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.
105 .PP
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
110 .BR tc (8)
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.
116 .PP
117 The same eBPF program can be attached to multiple events and different
118 eBPF programs can access the same map:
119 .PP
120 .in +4n
121 .EX
122 tracing tracing tracing packet packet packet
123 event A event B event C on eth0 on eth1 on eth2
124 | | | | | \(ha
125 | | | | v |
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 |\-\-
131 .EE
132 .in
133 .\"
134 .SS Arguments
135 The operation to be performed by the
136 .BR bpf ()
137 system call is determined by the
138 .I cmd
139 argument.
140 Each operation takes an accompanying argument,
141 provided via
142 .IR attr ,
143 which is a pointer to a union of type
144 .I bpf_attr
145 (see below).
146 The
147 .I size
148 argument is the size of the union pointed to by
149 .IR attr .
150 .PP
151 The value provided in
152 .I cmd
153 is one of the following:
154 .TP
155 .B BPF_MAP_CREATE
156 Create a map and return a file descriptor that refers to the map.
157 The close-on-exec file descriptor flag (see
158 .BR fcntl (2))
159 is automatically enabled for the new file descriptor.
160 .TP
161 .B BPF_MAP_LOOKUP_ELEM
162 Look up an element by key in a specified map and return its value.
163 .TP
164 .B BPF_MAP_UPDATE_ELEM
165 Create or update an element (key/value pair) in a specified map.
166 .TP
167 .B BPF_MAP_DELETE_ELEM
168 Look up and delete an element by key in a specified map.
169 .TP
170 .B BPF_MAP_GET_NEXT_KEY
171 Look up an element by key in a specified map and return the key
172 of the next element.
173 .TP
174 .B BPF_PROG_LOAD
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
178 .BR fcntl (2))
179 is automatically enabled for the new file descriptor.
180 .IP
181 The
182 .I bpf_attr
183 union consists of various anonymous structures that are used by different
184 .BR bpf ()
185 commands:
186 .PP
187 .in +4n
188 .EX
189 union bpf_attr {
190 struct { /* Used by BPF_MAP_CREATE */
191 __u32 map_type;
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
195 in a map */
196 };
198 struct { /* Used by BPF_MAP_*_ELEM and BPF_MAP_GET_NEXT_KEY
199 commands */
200 __u32 map_fd;
201 __aligned_u64 key;
202 union {
203 __aligned_u64 value;
204 __aligned_u64 next_key;
205 };
206 __u64 flags;
207 };
209 struct { /* Used by BPF_PROG_LOAD */
210 __u32 prog_type;
211 __u32 insn_cnt;
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
217 buffer */
218 __u32 kern_version;
219 /* checked when prog_type=kprobe
220 (since Linux 4.1) */
221 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
222 };
223 } __attribute__((aligned(8)));
224 .EE
225 .in
226 .\"
227 .SS eBPF maps
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.
231 .PP
232 Each map type has the following attributes:
233 .IP * 3
234 type
235 .IP *
236 maximum number of elements
237 .IP *
238 key size in bytes
239 .IP *
240 value size in bytes
241 .PP
242 The following wrapper functions demonstrate how various
243 .BR bpf ()
244 commands can be used to access the maps.
245 The functions use the
246 .I cmd
247 argument to invoke different operations.
248 .TP
249 .B BPF_MAP_CREATE
250 The
251 .B BPF_MAP_CREATE
252 command creates a new map,
253 returning a new file descriptor that refers to the map.
254 .IP
255 .in +4n
256 .EX
257 int
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)
262 {
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
268 };
270 return bpf(BPF_MAP_CREATE, &attr, sizeof(attr));
271 }
272 .EE
273 .in
274 .IP
275 The new map has the type specified by
276 .IR map_type ,
277 and attributes as specified in
278 .IR key_size ,
279 .IR value_size ,
280 and
281 .IR max_entries .
282 On success, this operation returns a file descriptor.
283 On error, \-1 is returned and
284 .I errno
285 is set to
286 .BR EINVAL ,
287 .BR EPERM ,
288 or
289 .BR ENOMEM .
290 .IP
291 The
292 .I key_size
293 and
294 .I value_size
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
299 .I key
300 and to check that the program doesn't access the map element
301 .I value
302 beyond the specified
303 .IR value_size .
304 For example, when a map is created with a
305 .I key_size
306 of 8 and the eBPF program calls
307 .IP
308 .in +4n
309 .EX
310 bpf_map_lookup_elem(map_fd, fp \- 4)
311 .EE
312 .in
313 .IP
314 the program will be rejected,
315 since the in-kernel helper function
316 .IP
317 .in +4n
318 .EX
319 bpf_map_lookup_elem(map_fd, void *key)
320 .EE
321 .in
322 .IP
323 expects to read 8 bytes from the location pointed to by
324 .IR key ,
325 but the
326 .I fp\ \-\ 4
327 (where
328 .I fp
329 is the top of the stack)
330 starting address will cause out-of-bounds stack access.
331 .IP
332 Similarly, when a map is created with a
333 .I value_size
334 of 1 and the eBPF program contains
335 .IP
336 .in +4n
337 .EX
338 value = bpf_map_lookup_elem(...);
339 *(u32 *) value = 1;
340 .EE
341 .in
342 .IP
343 the program will be rejected, since it accesses the
344 .I value
345 pointer beyond the specified 1 byte
346 .I value_size
347 limit.
348 .IP
349 Currently, the following values are supported for
350 .IR map_type :
351 .IP
352 .in +4n
353 .EX
354 enum bpf_map_type {
355 BPF_MAP_TYPE_UNSPEC, /* Reserve 0 as invalid map type */
356 BPF_MAP_TYPE_HASH,
357 BPF_MAP_TYPE_ARRAY,
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,
369 BPF_MAP_TYPE_DEVMAP,
370 BPF_MAP_TYPE_SOCKMAP,
371 BPF_MAP_TYPE_CPUMAP,
372 BPF_MAP_TYPE_XSKMAP,
373 BPF_MAP_TYPE_SOCKHASH,
374 BPF_MAP_TYPE_CGROUP_STORAGE,
375 BPF_MAP_TYPE_REUSEPORT_SOCKARRAY,
376 BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE,
377 BPF_MAP_TYPE_QUEUE,
378 BPF_MAP_TYPE_STACK,
379 /* See /usr/include/linux/bpf.h for the full list. */
380 };
381 .EE
382 .in
383 .IP
384 .I map_type
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
388 For all map types,
389 eBPF programs access maps with the same
390 .BR bpf_map_lookup_elem ()
391 and
392 .BR bpf_map_update_elem ()
393 helper functions.
394 Further details of the various map types are given below.
395 .TP
396 .B BPF_MAP_LOOKUP_ELEM
397 The
398 .B BPF_MAP_LOOKUP_ELEM
399 command looks up an element with a given
400 .I key
401 in the map referred to by the file descriptor
402 .IR fd .
403 .IP
404 .in +4n
405 .EX
406 int
407 bpf_lookup_elem(int fd, const void *key, void *value)
408 {
409 union bpf_attr attr = {
410 .map_fd = fd,
411 .key = ptr_to_u64(key),
412 .value = ptr_to_u64(value),
413 };
415 return bpf(BPF_MAP_LOOKUP_ELEM, &attr, sizeof(attr));
416 }
417 .EE
418 .in
419 .IP
420 If an element is found,
421 the operation returns zero and stores the element's value into
422 .IR value ,
423 which must point to a buffer of
424 .I value_size
425 bytes.
426 .IP
427 If no element is found, the operation returns \-1 and sets
428 .I errno
429 to
430 .BR ENOENT .
431 .TP
432 .B BPF_MAP_UPDATE_ELEM
433 The
434 .B BPF_MAP_UPDATE_ELEM
435 command
436 creates or updates an element with a given
437 .I key/value
438 in the map referred to by the file descriptor
439 .IR fd .
440 .IP
441 .in +4n
442 .EX
443 int
444 bpf_update_elem(int fd, const void *key, const void *value,
445 uint64_t flags)
446 {
447 union bpf_attr attr = {
448 .map_fd = fd,
449 .key = ptr_to_u64(key),
450 .value = ptr_to_u64(value),
451 .flags = flags,
452 };
454 return bpf(BPF_MAP_UPDATE_ELEM, &attr, sizeof(attr));
455 }
456 .EE
457 .in
458 .IP
459 The
460 .I flags
461 argument should be specified as one of the following:
462 .RS
463 .TP
464 .B BPF_ANY
465 Create a new element or update an existing element.
466 .TP
467 .B BPF_NOEXIST
468 Create a new element only if it did not exist.
469 .TP
470 .B BPF_EXIST
471 Update an existing element.
472 .RE
473 .IP
474 On success, the operation returns zero.
475 On error, \-1 is returned and
476 .I errno
477 is set to
478 .BR EINVAL ,
479 .BR EPERM ,
480 .BR ENOMEM ,
481 or
482 .BR E2BIG .
483 .B E2BIG
484 indicates that the number of elements in the map reached the
485 .I max_entries
486 limit specified at map creation time.
487 .B EEXIST
488 will be returned if
489 .I flags
490 specifies
491 .B BPF_NOEXIST
492 and the element with
493 .I key
494 already exists in the map.
495 .B ENOENT
496 will be returned if
497 .I flags
498 specifies
499 .B BPF_EXIST
500 and the element with
501 .I key
502 doesn't exist in the map.
503 .TP
504 .B BPF_MAP_DELETE_ELEM
505 The
506 .B BPF_MAP_DELETE_ELEM
507 command
508 deletes the element whose key is
509 .I key
510 from the map referred to by the file descriptor
511 .IR fd .
512 .IP
513 .in +4n
514 .EX
515 int
516 bpf_delete_elem(int fd, const void *key)
517 {
518 union bpf_attr attr = {
519 .map_fd = fd,
520 .key = ptr_to_u64(key),
521 };
523 return bpf(BPF_MAP_DELETE_ELEM, &attr, sizeof(attr));
524 }
525 .EE
526 .in
527 .IP
528 On success, zero is returned.
529 If the element is not found, \-1 is returned and
530 .I errno
531 is set to
532 .BR ENOENT .
533 .TP
534 .B BPF_MAP_GET_NEXT_KEY
535 The
536 .B BPF_MAP_GET_NEXT_KEY
537 command looks up an element by
538 .I key
539 in the map referred to by the file descriptor
540 .I fd
541 and sets the
542 .I next_key
543 pointer to the key of the next element.
544 .IP
545 .in +4n
546 .EX
547 int
548 bpf_get_next_key(int fd, const void *key, void *next_key)
549 {
550 union bpf_attr attr = {
551 .map_fd = fd,
552 .key = ptr_to_u64(key),
553 .next_key = ptr_to_u64(next_key),
554 };
556 return bpf(BPF_MAP_GET_NEXT_KEY, &attr, sizeof(attr));
557 }
558 .EE
559 .in
560 .IP
561 If
562 .I key
563 is found, the operation returns zero and sets the
564 .I next_key
565 pointer to the key of the next element.
566 If
567 .I key
568 is not found, the operation returns zero and sets the
569 .I next_key
570 pointer to the key of the first element.
571 If
572 .I key
573 is the last element, \-1 is returned and
574 .I errno
575 is set to
576 .BR ENOENT .
577 Other possible
578 .I errno
579 values are
580 .BR ENOMEM ,
581 .BR EFAULT ,
582 .BR EPERM ,
583 and
584 .BR EINVAL .
585 This method can be used to iterate over all elements in the map.
586 .TP
587 .B close(map_fd)
588 Delete the map referred to by the file descriptor
589 .IR map_fd .
590 When the user-space program that created a map exits, all maps will
591 be deleted automatically (but see NOTES).
592 .\"
593 .SS eBPF map types
594 The following map types are supported:
595 .TP
596 .B BPF_MAP_TYPE_HASH
597 .\" commit 0f8e4bd8a1fc8c4185f1630061d0a1f2d197a475
598 Hash-table maps have the following characteristics:
599 .RS
600 .IP * 3
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.
604 .IP *
605 The kernel takes care of allocating and freeing key/value pairs.
606 .IP *
607 The
608 .BR map_update_elem ()
609 helper will fail to insert new element when the
610 .I max_entries
611 limit is reached.
612 (This ensures that eBPF programs cannot exhaust memory.)
613 .IP *
614 .BR map_update_elem ()
615 replaces existing elements atomically.
616 .RE
617 .IP
618 Hash-table maps are
619 optimized for speed of lookup.
620 .TP
621 .B BPF_MAP_TYPE_ARRAY
622 .\" commit 28fbcfa08d8ed7c5a50d41a0433aad222835e8e3
623 Array maps have the following characteristics:
624 .RS
625 .IP * 3
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
632 .I value_size
633 are constant for the life of the eBPF program.
634 In other words,
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.
638 .IP *
639 All array elements pre-allocated and zero initialized at init time
640 .IP *
641 The key is an array index, and must be exactly four bytes.
642 .IP *
643 .BR map_delete_elem ()
644 fails with the error
645 .BR EINVAL ,
646 since elements cannot be deleted.
647 .IP *
648 .BR map_update_elem ()
649 replaces elements in a
650 .B nonatomic
651 fashion;
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:
654 the atomic built-in
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.
662 .RE
663 .IP
664 Among the uses for array maps are the following:
665 .RS
666 .IP * 3
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.
670 .IP *
671 Aggregation of tracing events into a fixed set of buckets.
672 .IP *
673 Accounting of networking events, for example, number of packets and packet
674 sizes.
675 .RE
676 .TP
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.
680 Thus, both the
681 .I key_size
682 and
683 .I value_size
684 must be exactly four bytes.
685 This map is used in conjunction with the
686 .BR bpf_tail_call ()
687 helper.
688 .IP
689 This means that an eBPF program with a program array map attached to it
690 can call from kernel side into
691 .IP
692 .in +4n
693 .EX
694 void bpf_tail_call(void *context, void *prog_map,
695 unsigned int index);
696 .EE
697 .in
698 .IP
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.
705 .IP
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,
709 or the limit of 32
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.
714 .IP
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.
725 .\"
726 .SS eBPF programs
727 The
728 .B BPF_PROG_LOAD
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.
732 .PP
733 .in +4n
734 .EX
735 char bpf_log_buf[LOG_BUF_SIZE];
737 int
738 bpf_prog_load(enum bpf_prog_type type,
739 const struct bpf_insn *insns, int insn_cnt,
740 const char *license)
741 {
742 union bpf_attr attr = {
743 .prog_type = type,
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,
749 .log_level = 1,
750 };
752 return bpf(BPF_PROG_LOAD, &attr, sizeof(attr));
753 }
754 .EE
755 .in
756 .PP
757 .I prog_type
758 is one of the available program types:
759 .IP
760 .in +4n
761 .EX
762 enum bpf_prog_type {
763 BPF_PROG_TYPE_UNSPEC, /* Reserve 0 as invalid
764 program type */
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,
770 BPF_PROG_TYPE_XDP,
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. */
788 };
789 .EE
790 .in
791 .PP
792 For further details of eBPF program types, see below.
793 .PP
794 The remaining fields of
795 .I bpf_attr
796 are set as follows:
797 .IP * 3
798 .I insns
799 is an array of
800 .I "struct bpf_insn"
801 instructions.
802 .IP *
803 .I insn_cnt
804 is the number of instructions in the program referred to by
805 .IR insns .
806 .IP *
807 .I license
808 is a license string, which must be GPL compatible to call helper functions
809 marked
810 .IR gpl_only .
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.)
813 .IP *
814 .I log_buf
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.
821 .IP *
822 .I log_size
823 size of the buffer pointed to by
824 .IR log_buf .
825 If the size of the buffer is not large enough to store all
826 verifier messages, \-1 is returned and
827 .I errno
828 is set to
829 .BR ENOSPC .
830 .IP *
831 .I log_level
832 verbosity level of the verifier.
833 A value of zero means that the verifier will not provide a log;
834 in this case,
835 .I log_buf
836 must be a NULL pointer, and
837 .I log_size
838 must be zero.
839 .PP
840 Applying
841 .BR close (2)
842 to the file descriptor returned by
843 .B BPF_PROG_LOAD
844 will unload the eBPF program (but see NOTES).
845 .PP
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.
848 For example,
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.
855 .\"
856 .\"
857 .SS eBPF program types
858 The eBPF program type
859 .RI ( prog_type )
860 determines the subset of kernel helper functions that the program
861 may call.
862 The program type also determines the program input (context)\(emthe
863 format of
864 .I "struct bpf_context"
865 (which is the data blob passed into the eBPF program as the first argument).
866 .\"
867 .\" FIXME
868 .\" Somewhere in this page we need a general introduction to the
869 .\" bpf_context. For example, how does a BPF program access the
870 .\" context?
871 .PP
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).
875 Similarly,
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.
878 .PP
879 The set of functions available to eBPF programs of a given type may increase
880 in the future.
881 .PP
882 The following program types are supported:
883 .TP
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
887 is:
888 .IP
889 .in +4n
890 .EX
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 */
897 .EE
898 .in
899 .IP
900 The
901 .I bpf_context
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
907 .\"
908 .\" Alexei commented:
909 .\" Actually now in case of SOCKET_FILTER, SCHED_CLS, SCHED_ACT
910 .\" the program can now access skb fields.
911 .\"
912 .TP
913 .BR BPF_PROG_TYPE_KPROBE " (since Linux 4.1)"
914 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
915 [To be documented]
916 .\" FIXME Document this program type
917 .\" Describe allowed helper functions for this program type
918 .\" Describe bpf_context for this program type
919 .\"
920 .\" FIXME We need text here to describe 'kern_version'
921 .TP
922 .BR BPF_PROG_TYPE_SCHED_CLS " (since Linux 4.1)"
923 .\" commit 96be4325f443dbbfeb37d2a157675ac0736531a1
924 .\" commit e2e9b6541dd4b31848079da80fe2253daaafb549
925 [To be documented]
926 .\" FIXME Document this program type
927 .\" Describe allowed helper functions for this program type
928 .\" Describe bpf_context for this program type
929 .TP
930 .BR BPF_PROG_TYPE_SCHED_ACT " (since Linux 4.1)"
931 .\" commit 94caee8c312d96522bcdae88791aaa9ebcd5f22c
932 .\" commit a8cb5f556b567974d75ea29c15181c445c541b1f
933 [To be documented]
934 .\" FIXME Document this program type
935 .\" Describe allowed helper functions for this program type
936 .\" Describe bpf_context for this program type
937 .SS Events
938 Once a program is loaded, it can be attached to an event.
939 Various kernel subsystems have different ways to do so.
940 .PP
941 Since Linux 3.19,
942 .\" commit 89aa075832b0da4402acebd698d0411dcc82d03e
943 the following call will attach the program
944 .I prog_fd
945 to the socket
946 .IR sockfd ,
947 which was created by an earlier call to
948 .BR socket (2):
949 .PP
950 .in +4n
951 .EX
952 setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_BPF,
953 &prog_fd, sizeof(prog_fd));
954 .EE
955 .in
956 .PP
957 Since Linux 4.1,
958 .\" commit 2541517c32be2531e0da59dfd7efc1ce844644f5
959 the following call may be used to attach
960 the eBPF program referred to by the file descriptor
961 .I prog_fd
962 to a perf event file descriptor,
963 .IR event_fd ,
964 that was created by a previous call to
965 .BR perf_event_open (2):
966 .PP
967 .in +4n
968 .EX
969 ioctl(event_fd, PERF_EVENT_IOC_SET_BPF, prog_fd);
970 .EE
971 .in
972 .\"
973 .\"
974 .SH RETURN VALUE
975 For a successful call, the return value depends on the operation:
976 .TP
977 .B BPF_MAP_CREATE
978 The new file descriptor associated with the eBPF map.
979 .TP
980 .B BPF_PROG_LOAD
981 The new file descriptor associated with the eBPF program.
982 .TP
983 All other commands
984 Zero.
985 .PP
986 On error, \-1 is returned, and
987 .I errno
988 is set to indicate the error.
989 .SH ERRORS
990 .TP
991 .B E2BIG
992 The eBPF program is too large or a map reached the
993 .I max_entries
994 limit (maximum number of elements).
995 .TP
996 .B EACCES
997 For
998 .BR BPF_PROG_LOAD ,
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
1006 .BR bpf ()
1007 again with
1008 .I log_level = 1
1009 and examine
1010 .I log_buf
1011 for the specific reason provided by the verifier.
1012 .TP
1013 .B EBADF
1014 .I fd
1015 is not an open file descriptor.
1016 .TP
1017 .B EFAULT
1018 One of the pointers
1019 .RI ( key
1020 or
1021 .I value
1022 or
1023 .I log_buf
1024 or
1025 .IR insns )
1026 is outside the accessible address space.
1027 .TP
1028 .B EINVAL
1029 The value specified in
1030 .I cmd
1031 is not recognized by this kernel.
1032 .TP
1033 .B EINVAL
1034 For
1035 .BR BPF_MAP_CREATE ,
1036 either
1037 .I map_type
1038 or attributes are invalid.
1039 .TP
1040 .B EINVAL
1041 For
1042 .B BPF_MAP_*_ELEM
1043 commands,
1044 some of the fields of
1045 .I "union bpf_attr"
1046 that are not used by this command
1047 are not set to zero.
1048 .TP
1049 .B EINVAL
1050 For
1051 .BR BPF_PROG_LOAD ,
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.
1056 .TP
1057 .B ENOENT
1058 For
1059 .B BPF_MAP_LOOKUP_ELEM
1060 or
1061 .BR BPF_MAP_DELETE_ELEM ,
1062 indicates that the element with the given
1063 .I key
1064 was not found.
1065 .TP
1066 .B ENOMEM
1067 Cannot allocate sufficient memory.
1068 .TP
1069 .B EPERM
1070 The call was made without sufficient privilege
1071 (without the
1072 .B CAP_SYS_ADMIN
1073 capability).
1074 .SH VERSIONS
1075 The
1076 .BR bpf ()
1077 system call first appeared in Linux 3.18.
1078 .SH CONFORMING TO
1079 The
1080 .BR bpf ()
1081 system call is Linux-specific.
1082 .SH NOTES
1083 Prior to Linux 4.4, all
1084 .BR bpf ()
1085 commands require the caller to have the
1086 .B CAP_SYS_ADMIN
1087 capability.
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().
1097 .IP * 3
1098 get_random
1099 .PD 0
1100 .IP *
1101 get_smp_processor_id
1102 .IP *
1103 tail_call
1104 .IP *
1105 ktime_get_ns
1106 .PD 1
1107 .PP
1108 Unprivileged access may be blocked by writing the value 1 to the file
1109 .IR /proc/sys/kernel/unprivileged_bpf_disabled .
1110 .PP
1111 eBPF objects (maps and programs) can be shared between processes.
1112 For example, after
1113 .BR fork (2),
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
1119 .BR dup (2)
1120 and similar calls.
1121 An eBPF object is deallocated only after all file descriptors
1122 referring to the object have been closed.
1123 .PP
1124 eBPF programs can be written in a restricted C that is compiled (using the
1125 .B clang
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
1135 .PP
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 :
1143 .IP 0 3
1144 Disable JIT compilation (default).
1145 .IP 1
1146 Normal compilation.
1147 .IP 2
1148 Debugging mode.
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.
1153 .PP
1154 Since Linux 4.15,
1155 .\" commit 290af86629b25ffd1ed6232c4e9107da031705cb
1156 the kernel may configured with the
1157 .B CONFIG_BPF_JIT_ALWAYS_ON
1158 option.
1159 In this case, the JIT compiler is always enabled, and the
1160 .I bpf_jit_enable
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.)
1164 .PP
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:
1170 .IP * 3
1171 x86-64 (since Linux 3.18; cBPF since Linux 3.0);
1172 .\" commit 0a14842f5a3c0e88a1e59fac5c3025db39721f74
1173 .PD 0
1174 .IP *
1175 ARM32 (since Linux 3.18; cBPF since Linux 3.4);
1176 .\" commit ddecdfcea0ae891f782ae853771c867ab51024c2
1177 .IP *
1178 SPARC 32 (since Linux 3.18; cBPF since Linux 3.5);
1179 .\" commit 2809a2087cc44b55e4377d7b9be3f7f5d2569091
1180 .IP *
1181 ARM-64 (since Linux 3.18);
1182 .\" commit e54bcde3d69d40023ae77727213d14f920eb264a
1183 .IP *
1184 s390 (since Linux 4.1; cBPF since Linux 3.7);
1185 .\" commit c10302efe569bfd646b4c22df29577a4595b4580
1186 .IP *
1187 PowerPC 64 (since Linux 4.8; cBPF since Linux 3.1);
1188 .\" commit 0ca87f05ba8bdc6791c14878464efc901ad71e99
1189 .\" commit 156d0e290e969caba25f1851c52417c14d141b24
1190 .IP *
1191 SPARC 64 (since Linux 4.12);
1192 .\" commit 7a12b5031c6b947cc13918237ae652b536243b76
1193 .IP *
1194 x86-32 (since Linux 4.18);
1195 .\" commit 03f5781be2c7b7e728d724ac70ba10799cc710d7
1196 .IP *
1197 MIPS 64 (since Linux 4.18; cBPF since Linux 3.16);
1198 .\" commit c6610de353da5ca6eee5b8960e838a87a90ead0c
1199 .\" commit f381bf6d82f032b7410185b35d000ea370ac706b
1200 .IP *
1201 riscv (since Linux 5.1).
1202 .\" commit 2353ecc6f91fd15b893fa01bf85a1c7a823ee4f2
1203 .PD
1204 .SH EXAMPLES
1205 .EX
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)]
1210 * map[r0]++
1211 * 3. attach prog_fd to raw socket via setsockopt()
1212 * 4. print number of received TCP/UDP packets every second
1213 */
1214 int
1215 main(int argc, char *argv[])
1216 {
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);
1222 if (map_fd < 0) {
1223 printf("failed to create map \(aq%s\(aq\en", strerror(errno));
1224 /* likely not run as root */
1225 return 1;
1226 }
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 */
1244 .\" == atomic64_add
1245 BPF_MOV64_IMM(BPF_REG_0, 0), /* r0 = 0 */
1246 BPF_EXIT_INSN(), /* return r0 */
1247 };
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);
1257 for (;;) {
1258 key = IPPROTO_TCP;
1259 assert(bpf_lookup_elem(map_fd, &key, &tcp_cnt) == 0);
1260 key = IPPROTO_UDP;
1261 assert(bpf_lookup_elem(map_fd, &key, &udp_cnt) == 0);
1262 printf("TCP %lld UDP %lld packets\en", tcp_cnt, udp_cnt);
1263 sleep(1);
1264 }
1266 return 0;
1267 }
1268 .EE
1269 .PP
1270 Some complete working code can be found in the
1271 .I samples/bpf
1272 directory in the kernel source tree.
1273 .SH SEE ALSO
1274 .BR seccomp (2),
1275 .BR bpf\-helpers (7),
1276 .BR socket (7),
1277 .BR tc (8),
1278 .BR tc\-bpf (8)
1279 .PP
1280 Both classic and extended BPF are explained in the kernel source file
1281 .IR Documentation/networking/filter.txt .