Skip to content

Commit 89de2db

Browse files
kuba-mookuba-moo
committed
Daniel Borkmann says: ==================== pull-request: bpf-next 2024-04-29 We've added 147 non-merge commits during the last 32 day(s) which contain a total of 158 files changed, 9400 insertions(+), 2213 deletions(-). The main changes are: 1) Add an internal-only BPF per-CPU instruction for resolving per-CPU memory addresses and implement support in x86 BPF JIT. This allows inlining per-CPU array and hashmap lookups and the bpf_get_smp_processor_id() helper, from Andrii Nakryiko. 2) Add BPF link support for sk_msg and sk_skb programs, from Yonghong Song. 3) Optimize x86 BPF JIT's emit_mov_imm64, and add support for various atomics in bpf_arena which can be JITed as a single x86 instruction, from Alexei Starovoitov. 4) Add support for passing mark with bpf_fib_lookup helper, from Anton Protopopov. 5) Add a new bpf_wq API for deferring events and refactor sleepable bpf_timer code to keep common code where possible, from Benjamin Tissoires. 6) Fix BPF_PROG_TEST_RUN infra with regards to bpf_dummy_struct_ops programs to check when NULL is passed for non-NULLable parameters, from Eduard Zingerman. 7) Harden the BPF verifier's and/or/xor value tracking, from Harishankar Vishwanathan. 8) Introduce crypto kfuncs to make BPF programs able to utilize the kernel crypto subsystem, from Vadim Fedorenko. 9) Various improvements to the BPF instruction set standardization doc, from Dave Thaler. 10) Extend libbpf APIs to partially consume items from the BPF ringbuffer, from Andrea Righi. 11) Bigger batch of BPF selftests refactoring to use common network helpers and to drop duplicate code, from Geliang Tang. 12) Support bpf_tail_call_static() helper for BPF programs with GCC 13, from Jose E. Marchesi. 13) Add bpf_preempt_{disable,enable}() kfuncs in order to allow a BPF program to have code sections where preemption is disabled, from Kumar Kartikeya Dwivedi. 14) Allow invoking BPF kfuncs from BPF_PROG_TYPE_SYSCALL programs, from David Vernet. 15) Extend the BPF verifier to allow different input maps for a given bpf_for_each_map_elem() helper call in a BPF program, from Philo Lu. 16) Add support for PROBE_MEM32 and bpf_addr_space_cast instructions for riscv64 and arm64 JITs to enable BPF Arena, from Puranjay Mohan. 17) Shut up a false-positive KMSAN splat in interpreter mode by unpoison the stack memory, from Martin KaFai Lau. 18) Improve xsk selftest coverage with new tests on maximum and minimum hardware ring size configurations, from Tushar Vyavahare. 19) Various ReST man pages fixes as well as documentation and bash completion improvements for bpftool, from Rameez Rehman & Quentin Monnet. 20) Fix libbpf with regards to dumping subsequent char arrays, from Quentin Deslandes. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (147 commits) bpf, docs: Clarify PC use in instruction-set.rst bpf_helpers.h: Define bpf_tail_call_static when building with GCC bpf, docs: Add introduction for use in the ISA Internet Draft selftests/bpf: extend BPF_SOCK_OPS_RTT_CB test for srtt and mrtt_us bpf: add mrtt and srtt as BPF_SOCK_OPS_RTT_CB args selftests/bpf: dummy_st_ops should reject 0 for non-nullable params bpf: check bpf_dummy_struct_ops program params for test runs selftests/bpf: do not pass NULL for non-nullable params in dummy_st_ops selftests/bpf: adjust dummy_st_ops_success to detect additional error bpf: mark bpf_dummy_struct_ops.test_1 parameter as nullable selftests/bpf: Add ring_buffer__consume_n test. bpf: Add bpf_guard_preempt() convenience macro selftests: bpf: crypto: add benchmark for crypto functions selftests: bpf: crypto skcipher algo selftests bpf: crypto: add skcipher to bpf crypto bpf: make common crypto API for TC/XDP programs bpf: update the comment for BTF_FIELDS_MAX selftests/bpf: Fix wq test. selftests/bpf: Use make_sockaddr in test_sock_addr selftests/bpf: Use connect_to_addr in test_sock_addr ... ==================== Link: https://lore.kernel.org/r/20240429131657.19423-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2 parents b3f1a08 + 07801a2 commit 89de2db

158 files changed

Lines changed: 9400 additions & 2213 deletions

File tree

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

‎Documentation/bpf/standardization/instruction-set.rst‎

Lines changed: 62 additions & 47 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,11 @@
55
BPF Instruction Set Architecture (ISA)
66
======================================
77

8-
This document specifies the BPF instruction set architecture (ISA).
8+
eBPF (which is no longer an acronym for anything), also commonly
9+
referred to as BPF, is a technology with origins in the Linux kernel
10+
that can run untrusted programs in a privileged context such as an
11+
operating system kernel. This document specifies the BPF instruction
12+
set architecture (ISA).
913

1014
Documentation conventions
1115
=========================
@@ -43,7 +47,7 @@ a type's signedness (`S`) and bit width (`N`), respectively.
4347
===== =========
4448

4549
For example, `u32` is a type whose valid values are all the 32-bit unsigned
46-
numbers and `s16` is a types whose valid values are all the 16-bit signed
50+
numbers and `s16` is a type whose valid values are all the 16-bit signed
4751
numbers.
4852

4953
Functions
@@ -108,7 +112,7 @@ conformance group means it must support all instructions in that conformance
108112
group.
109113

110114
The use of named conformance groups enables interoperability between a runtime
111-
that executes instructions, and tools as such compilers that generate
115+
that executes instructions, and tools such as compilers that generate
112116
instructions for the runtime. Thus, capability discovery in terms of
113117
conformance groups might be done manually by users or automatically by tools.
114118

@@ -181,10 +185,13 @@ A basic instruction is encoded as follows::
181185
(`64-bit immediate instructions`_ reuse this field for other purposes)
182186

183187
**dst_reg**
184-
destination register number (0-10)
188+
destination register number (0-10), unless otherwise specified
189+
(future instructions might reuse this field for other purposes)
185190

186191
**offset**
187-
signed integer offset used with pointer arithmetic
192+
signed integer offset used with pointer arithmetic, except where
193+
otherwise specified (some arithmetic instructions reuse this field
194+
for other purposes)
188195

189196
**imm**
190197
signed integer immediate value
@@ -228,10 +235,12 @@ This is depicted in the following figure::
228235
operation to perform, encoded as explained above
229236

230237
**regs**
231-
The source and destination register numbers, encoded as explained above
238+
The source and destination register numbers (unless otherwise
239+
specified), encoded as explained above
232240

233241
**offset**
234-
signed integer offset used with pointer arithmetic
242+
signed integer offset used with pointer arithmetic, unless
243+
otherwise specified
235244

236245
**imm**
237246
signed integer immediate value
@@ -342,8 +351,8 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
342351

343352
dst = dst ^ imm
344353

345-
Note that most instructions have instruction offset of 0. Only three instructions
346-
(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset.
354+
Note that most arithmetic instructions have 'offset' set to 0. Only three instructions
355+
(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'.
347356

348357
Division, multiplication, and modulo operations for ``ALU`` are part
349358
of the "divmul32" conformance group, and division, multiplication, and
@@ -365,15 +374,15 @@ Note that there are varying definitions of the signed modulo operation
365374
when the dividend or divisor are negative, where implementations often
366375
vary by language such that Python, Ruby, etc. differ from C, Go, Java,
367376
etc. This specification requires that signed modulo use truncated division
368-
(where -13 % 3 == -1) as implemented in C, Go, etc.:
377+
(where -13 % 3 == -1) as implemented in C, Go, etc.::
369378

370379
a % n = a - n * trunc(a / n)
371380

372381
The ``MOVSX`` instruction does a move operation with sign extension.
373-
``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
374-
bit operands, and zeroes the remaining upper 32 bits.
382+
``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into
383+
32-bit operands, and zeroes the remaining upper 32 bits.
375384
``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
376-
operands into 64 bit operands. Unlike other arithmetic instructions,
385+
operands into 64-bit operands. Unlike other arithmetic instructions,
377386
``MOVSX`` is only defined for register source operands (``X``).
378387

379388
The ``NEG`` instruction is only defined when the source bit is clear
@@ -411,19 +420,19 @@ conformance group.
411420

412421
Examples:
413422

414-
``{END, TO_LE, ALU}`` with imm = 16/32/64 means::
423+
``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means::
415424

416425
dst = htole16(dst)
417426
dst = htole32(dst)
418427
dst = htole64(dst)
419428

420-
``{END, TO_BE, ALU}`` with imm = 16/32/64 means::
429+
``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means::
421430

422431
dst = htobe16(dst)
423432
dst = htobe32(dst)
424433
dst = htobe64(dst)
425434

426-
``{END, TO_LE, ALU64}`` with imm = 16/32/64 means::
435+
``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means::
427436

428437
dst = bswap16(dst)
429438
dst = bswap32(dst)
@@ -438,27 +447,33 @@ otherwise identical operations, and indicates the base64 conformance
438447
group unless otherwise specified.
439448
The 'code' field encodes the operation as below:
440449

441-
======== ===== ======= =============================== ===================================================
442-
code value src_reg description notes
443-
======== ===== ======= =============================== ===================================================
444-
JA 0x0 0x0 PC += offset {JA, K, JMP} only
445-
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
450+
======== ===== ======= ================================= ===================================================
451+
code value src_reg description notes
452+
======== ===== ======= ================================= ===================================================
453+
JA 0x0 0x0 PC += offset {JA, K, JMP} only
454+
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
446455
JEQ 0x1 any PC += offset if dst == src
447-
JGT 0x2 any PC += offset if dst > src unsigned
448-
JGE 0x3 any PC += offset if dst >= src unsigned
456+
JGT 0x2 any PC += offset if dst > src unsigned
457+
JGE 0x3 any PC += offset if dst >= src unsigned
449458
JSET 0x4 any PC += offset if dst & src
450459
JNE 0x5 any PC += offset if dst != src
451-
JSGT 0x6 any PC += offset if dst > src signed
452-
JSGE 0x7 any PC += offset if dst >= src signed
453-
CALL 0x8 0x0 call helper function by address {CALL, K, JMP} only, see `Helper functions`_
454-
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
455-
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
456-
EXIT 0x9 0x0 return {CALL, K, JMP} only
457-
JLT 0xa any PC += offset if dst < src unsigned
458-
JLE 0xb any PC += offset if dst <= src unsigned
459-
JSLT 0xc any PC += offset if dst < src signed
460-
JSLE 0xd any PC += offset if dst <= src signed
461-
======== ===== ======= =============================== ===================================================
460+
JSGT 0x6 any PC += offset if dst > src signed
461+
JSGE 0x7 any PC += offset if dst >= src signed
462+
CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_
463+
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
464+
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
465+
EXIT 0x9 0x0 return {CALL, K, JMP} only
466+
JLT 0xa any PC += offset if dst < src unsigned
467+
JLE 0xb any PC += offset if dst <= src unsigned
468+
JSLT 0xc any PC += offset if dst < src signed
469+
JSLE 0xd any PC += offset if dst <= src signed
470+
======== ===== ======= ================================= ===================================================
471+
472+
where 'PC' denotes the program counter, and the offset to increment by
473+
is in units of 64-bit instructions relative to the instruction following
474+
the jump instruction. Thus 'PC += 1' skips execution of the next
475+
instruction if it's a basic instruction or results in undefined behavior
476+
if the next instruction is a 128-bit wide instruction.
462477

463478
The BPF program needs to store the return value into register R0 before doing an
464479
``EXIT``.
@@ -475,7 +490,7 @@ where 's>=' indicates a signed '>=' comparison.
475490

476491
gotol +imm
477492

478-
where 'imm' means the branch offset comes from insn 'imm' field.
493+
where 'imm' means the branch offset comes from the 'imm' field.
479494

480495
Note that there are two flavors of ``JA`` instructions. The
481496
``JMP`` class permits a 16-bit jump offset specified by the 'offset'
@@ -493,26 +508,26 @@ Helper functions
493508
Helper functions are a concept whereby BPF programs can call into a
494509
set of function calls exposed by the underlying platform.
495510

496-
Historically, each helper function was identified by an address
497-
encoded in the imm field. The available helper functions may differ
498-
for each program type, but address values are unique across all program types.
511+
Historically, each helper function was identified by a static ID
512+
encoded in the 'imm' field. The available helper functions may differ
513+
for each program type, but static IDs are unique across all program types.
499514

500515
Platforms that support the BPF Type Format (BTF) support identifying
501-
a helper function by a BTF ID encoded in the imm field, where the BTF ID
516+
a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
502517
identifies the helper name and type.
503518

504519
Program-local functions
505520
~~~~~~~~~~~~~~~~~~~~~~~
506521
Program-local functions are functions exposed by the same BPF program as the
507522
caller, and are referenced by offset from the call instruction, similar to
508-
``JA``. The offset is encoded in the imm field of the call instruction.
509-
A ``EXIT`` within the program-local function will return to the caller.
523+
``JA``. The offset is encoded in the 'imm' field of the call instruction.
524+
An ``EXIT`` within the program-local function will return to the caller.
510525

511526
Load and store instructions
512527
===========================
513528

514529
For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
515-
8-bit 'opcode' field is divided as::
530+
8-bit 'opcode' field is divided as follows::
516531

517532
+-+-+-+-+-+-+-+-+
518533
|mode |sz |class|
@@ -580,7 +595,7 @@ instructions that transfer data between a register and memory.
580595

581596
dst = *(signed size *) (src + offset)
582597

583-
Where size is one of: ``B``, ``H``, or ``W``, and
598+
Where '<size>' is one of: ``B``, ``H``, or ``W``, and
584599
'signed size' is one of: s8, s16, or s32.
585600

586601
Atomic operations
@@ -662,11 +677,11 @@ src_reg pseudocode imm type dst type
662677
======= ========================================= =========== ==============
663678
0x0 dst = (next_imm << 32) | imm integer integer
664679
0x1 dst = map_by_fd(imm) map fd map
665-
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
666-
0x3 dst = var_addr(imm) variable id data pointer
667-
0x4 dst = code_addr(imm) integer code pointer
680+
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address
681+
0x3 dst = var_addr(imm) variable id data address
682+
0x4 dst = code_addr(imm) integer code address
668683
0x5 dst = map_by_idx(imm) map index map
669-
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
684+
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address
670685
======= ========================================= =========== ==============
671686

672687
where

‎MAINTAINERS‎

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -3822,6 +3822,14 @@ F: kernel/bpf/tnum.c
38223822
F: kernel/bpf/trampoline.c
38233823
F: kernel/bpf/verifier.c
38243824

3825+
BPF [CRYPTO]
3826+
M: Vadim Fedorenko <vadim.fedorenko@linux.dev>
3827+
L: bpf@vger.kernel.org
3828+
S: Maintained
3829+
F: crypto/bpf_crypto_skcipher.c
3830+
F: include/linux/bpf_crypto.h
3831+
F: kernel/bpf/crypto.c
3832+
38253833
BPF [DOCUMENTATION] (Related to Standardization)
38263834
R: David Vernet <void@manifault.com>
38273835
L: bpf@vger.kernel.org

0 commit comments

Comments
 (0)