cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

bpftool-gen.rst (14952B)


      1.. SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
      2
      3================
      4bpftool-gen
      5================
      6-------------------------------------------------------------------------------
      7tool for BPF code-generation
      8-------------------------------------------------------------------------------
      9
     10:Manual section: 8
     11
     12.. include:: substitutions.rst
     13
     14SYNOPSIS
     15========
     16
     17	**bpftool** [*OPTIONS*] **gen** *COMMAND*
     18
     19	*OPTIONS* := { |COMMON_OPTIONS| | { **-L** | **--use-loader** } }
     20
     21	*COMMAND* := { **object** | **skeleton** | **help** }
     22
     23GEN COMMANDS
     24=============
     25
     26|	**bpftool** **gen object** *OUTPUT_FILE* *INPUT_FILE* [*INPUT_FILE*...]
     27|	**bpftool** **gen skeleton** *FILE* [**name** *OBJECT_NAME*]
     28|	**bpftool** **gen subskeleton** *FILE* [**name** *OBJECT_NAME*]
     29|	**bpftool** **gen min_core_btf** *INPUT* *OUTPUT* *OBJECT* [*OBJECT*...]
     30|	**bpftool** **gen help**
     31
     32DESCRIPTION
     33===========
     34	**bpftool gen object** *OUTPUT_FILE* *INPUT_FILE* [*INPUT_FILE*...]
     35		  Statically link (combine) together one or more *INPUT_FILE*'s
     36		  into a single resulting *OUTPUT_FILE*. All the files involved
     37		  are BPF ELF object files.
     38
     39		  The rules of BPF static linking are mostly the same as for
     40		  user-space object files, but in addition to combining data
     41		  and instruction sections, .BTF and .BTF.ext (if present in
     42		  any of the input files) data are combined together. .BTF
     43		  data is deduplicated, so all the common types across
     44		  *INPUT_FILE*'s will only be represented once in the resulting
     45		  BTF information.
     46
     47		  BPF static linking allows to partition BPF source code into
     48		  individually compiled files that are then linked into
     49		  a single resulting BPF object file, which can be used to
     50		  generated BPF skeleton (with **gen skeleton** command) or
     51		  passed directly into **libbpf** (using **bpf_object__open()**
     52		  family of APIs).
     53
     54	**bpftool gen skeleton** *FILE*
     55		  Generate BPF skeleton C header file for a given *FILE*.
     56
     57		  BPF skeleton is an alternative interface to existing libbpf
     58		  APIs for working with BPF objects. Skeleton code is intended
     59		  to significantly shorten and simplify code to load and work
     60		  with BPF programs from userspace side. Generated code is
     61		  tailored to specific input BPF object *FILE*, reflecting its
     62		  structure by listing out available maps, program, variables,
     63		  etc. Skeleton eliminates the need to lookup mentioned
     64		  components by name. Instead, if skeleton instantiation
     65		  succeeds, they are populated in skeleton structure as valid
     66		  libbpf types (e.g., **struct bpf_map** pointer) and can be
     67		  passed to existing generic libbpf APIs.
     68
     69		  In addition to simple and reliable access to maps and
     70		  programs, skeleton provides a storage for BPF links (**struct
     71		  bpf_link**) for each BPF program within BPF object. When
     72		  requested, supported BPF programs will be automatically
     73		  attached and resulting BPF links stored for further use by
     74		  user in pre-allocated fields in skeleton struct. For BPF
     75		  programs that can't be automatically attached by libbpf,
     76		  user can attach them manually, but store resulting BPF link
     77		  in per-program link field. All such set up links will be
     78		  automatically destroyed on BPF skeleton destruction. This
     79		  eliminates the need for users to manage links manually and
     80		  rely on libbpf support to detach programs and free up
     81		  resources.
     82
     83		  Another facility provided by BPF skeleton is an interface to
     84		  global variables of all supported kinds: mutable, read-only,
     85		  as well as extern ones. This interface allows to pre-setup
     86		  initial values of variables before BPF object is loaded and
     87		  verified by kernel. For non-read-only variables, the same
     88		  interface can be used to fetch values of global variables on
     89		  userspace side, even if they are modified by BPF code.
     90
     91		  During skeleton generation, contents of source BPF object
     92		  *FILE* is embedded within generated code and is thus not
     93		  necessary to keep around. This ensures skeleton and BPF
     94		  object file are matching 1-to-1 and always stay in sync.
     95		  Generated code is dual-licensed under LGPL-2.1 and
     96		  BSD-2-Clause licenses.
     97
     98		  It is a design goal and guarantee that skeleton interfaces
     99		  are interoperable with generic libbpf APIs. User should
    100		  always be able to use skeleton API to create and load BPF
    101		  object, and later use libbpf APIs to keep working with
    102		  specific maps, programs, etc.
    103
    104		  As part of skeleton, few custom functions are generated.
    105		  Each of them is prefixed with object name. Object name can
    106		  either be derived from object file name, i.e., if BPF object
    107		  file name is **example.o**, BPF object name will be
    108		  **example**. Object name can be also specified explicitly
    109		  through **name** *OBJECT_NAME* parameter. The following
    110		  custom functions are provided (assuming **example** as
    111		  the object name):
    112
    113		  - **example__open** and **example__open_opts**.
    114		    These functions are used to instantiate skeleton. It
    115		    corresponds to libbpf's **bpf_object__open**\ () API.
    116		    **_opts** variants accepts extra **bpf_object_open_opts**
    117		    options.
    118
    119		  - **example__load**.
    120		    This function creates maps, loads and verifies BPF
    121		    programs, initializes global data maps. It corresponds to
    122		    libppf's **bpf_object__load**\ () API.
    123
    124		  - **example__open_and_load** combines **example__open** and
    125		    **example__load** invocations in one commonly used
    126		    operation.
    127
    128		  - **example__attach** and **example__detach**
    129		    This pair of functions allow to attach and detach,
    130		    correspondingly, already loaded BPF object. Only BPF
    131		    programs of types supported by libbpf for auto-attachment
    132		    will be auto-attached and their corresponding BPF links
    133		    instantiated. For other BPF programs, user can manually
    134		    create a BPF link and assign it to corresponding fields in
    135		    skeleton struct. **example__detach** will detach both
    136		    links created automatically, as well as those populated by
    137		    user manually.
    138
    139		  - **example__destroy**
    140		    Detach and unload BPF programs, free up all the resources
    141		    used by skeleton and BPF object.
    142
    143		  If BPF object has global variables, corresponding structs
    144		  with memory layout corresponding to global data data section
    145		  layout will be created. Currently supported ones are: *.data*,
    146		  *.bss*, *.rodata*, and *.kconfig* structs/data sections.
    147		  These data sections/structs can be used to set up initial
    148		  values of variables, if set before **example__load**.
    149		  Afterwards, if target kernel supports memory-mapped BPF
    150		  arrays, same structs can be used to fetch and update
    151		  (non-read-only) data from userspace, with same simplicity
    152		  as for BPF side.
    153
    154	**bpftool gen subskeleton** *FILE*
    155		  Generate BPF subskeleton C header file for a given *FILE*.
    156
    157		  Subskeletons are similar to skeletons, except they do not own
    158		  the corresponding maps, programs, or global variables. They
    159		  require that the object file used to generate them is already
    160		  loaded into a *bpf_object* by some other means.
    161
    162		  This functionality is useful when a library is included into a
    163		  larger BPF program. A subskeleton for the library would have
    164		  access to all objects and globals defined in it, without
    165		  having to know about the larger program.
    166
    167		  Consequently, there are only two functions defined
    168		  for subskeletons:
    169
    170		  - **example__open(bpf_object\*)**
    171		    Instantiates a subskeleton from an already opened (but not
    172		    necessarily loaded) **bpf_object**.
    173
    174		  - **example__destroy()**
    175		    Frees the storage for the subskeleton but *does not* unload
    176		    any BPF programs or maps.
    177
    178	**bpftool** **gen min_core_btf** *INPUT* *OUTPUT* *OBJECT* [*OBJECT*...]
    179		  Generate a minimum BTF file as *OUTPUT*, derived from a given
    180		  *INPUT* BTF file, containing all needed BTF types so one, or
    181		  more, given eBPF objects CO-RE relocations may be satisfied.
    182
    183		  When kernels aren't compiled with CONFIG_DEBUG_INFO_BTF,
    184		  libbpf, when loading an eBPF object, has to rely on external
    185		  BTF files to be able to calculate CO-RE relocations.
    186
    187		  Usually, an external BTF file is built from existing kernel
    188		  DWARF data using pahole. It contains all the types used by
    189		  its respective kernel image and, because of that, is big.
    190
    191		  The min_core_btf feature builds smaller BTF files, customized
    192		  to one or multiple eBPF objects, so they can be distributed
    193		  together with an eBPF CO-RE based application, turning the
    194		  application portable to different kernel versions.
    195
    196		  Check examples bellow for more information how to use it.
    197
    198	**bpftool gen help**
    199		  Print short help message.
    200
    201OPTIONS
    202=======
    203	.. include:: common_options.rst
    204
    205	-L, --use-loader
    206		  For skeletons, generate a "light" skeleton (also known as "loader"
    207		  skeleton). A light skeleton contains a loader eBPF program. It does
    208		  not use the majority of the libbpf infrastructure, and does not need
    209		  libelf.
    210
    211EXAMPLES
    212========
    213**$ cat example1.bpf.c**
    214
    215::
    216
    217  #include <stdbool.h>
    218  #include <linux/ptrace.h>
    219  #include <linux/bpf.h>
    220  #include <bpf/bpf_helpers.h>
    221
    222  const volatile int param1 = 42;
    223  bool global_flag = true;
    224  struct { int x; } data = {};
    225
    226  SEC("raw_tp/sys_enter")
    227  int handle_sys_enter(struct pt_regs *ctx)
    228  {
    229  	static long my_static_var;
    230  	if (global_flag)
    231  		my_static_var++;
    232  	else
    233  		data.x += param1;
    234  	return 0;
    235  }
    236
    237**$ cat example2.bpf.c**
    238
    239::
    240
    241  #include <linux/ptrace.h>
    242  #include <linux/bpf.h>
    243  #include <bpf/bpf_helpers.h>
    244
    245  struct {
    246  	__uint(type, BPF_MAP_TYPE_HASH);
    247  	__uint(max_entries, 128);
    248  	__type(key, int);
    249  	__type(value, long);
    250  } my_map SEC(".maps");
    251
    252  SEC("raw_tp/sys_exit")
    253  int handle_sys_exit(struct pt_regs *ctx)
    254  {
    255  	int zero = 0;
    256  	bpf_map_lookup_elem(&my_map, &zero);
    257  	return 0;
    258  }
    259
    260This is example BPF application with two BPF programs and a mix of BPF maps
    261and global variables. Source code is split across two source code files.
    262
    263**$ clang -target bpf -g example1.bpf.c -o example1.bpf.o**
    264
    265**$ clang -target bpf -g example2.bpf.c -o example2.bpf.o**
    266
    267**$ bpftool gen object example.bpf.o example1.bpf.o example2.bpf.o**
    268
    269This set of commands compiles *example1.bpf.c* and *example2.bpf.c*
    270individually and then statically links respective object files into the final
    271BPF ELF object file *example.bpf.o*.
    272
    273**$ bpftool gen skeleton example.bpf.o name example | tee example.skel.h**
    274
    275::
    276
    277  /* SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) */
    278
    279  /* THIS FILE IS AUTOGENERATED! */
    280  #ifndef __EXAMPLE_SKEL_H__
    281  #define __EXAMPLE_SKEL_H__
    282
    283  #include <stdlib.h>
    284  #include <bpf/libbpf.h>
    285
    286  struct example {
    287  	struct bpf_object_skeleton *skeleton;
    288  	struct bpf_object *obj;
    289  	struct {
    290  		struct bpf_map *rodata;
    291  		struct bpf_map *data;
    292  		struct bpf_map *bss;
    293  		struct bpf_map *my_map;
    294  	} maps;
    295  	struct {
    296  		struct bpf_program *handle_sys_enter;
    297  		struct bpf_program *handle_sys_exit;
    298  	} progs;
    299  	struct {
    300  		struct bpf_link *handle_sys_enter;
    301  		struct bpf_link *handle_sys_exit;
    302  	} links;
    303  	struct example__bss {
    304  		struct {
    305  			int x;
    306  		} data;
    307  	} *bss;
    308  	struct example__data {
    309  		_Bool global_flag;
    310  		long int handle_sys_enter_my_static_var;
    311  	} *data;
    312  	struct example__rodata {
    313  		int param1;
    314  	} *rodata;
    315  };
    316
    317  static void example__destroy(struct example *obj);
    318  static inline struct example *example__open_opts(
    319                const struct bpf_object_open_opts *opts);
    320  static inline struct example *example__open();
    321  static inline int example__load(struct example *obj);
    322  static inline struct example *example__open_and_load();
    323  static inline int example__attach(struct example *obj);
    324  static inline void example__detach(struct example *obj);
    325
    326  #endif /* __EXAMPLE_SKEL_H__ */
    327
    328**$ cat example.c**
    329
    330::
    331
    332  #include "example.skel.h"
    333
    334  int main()
    335  {
    336  	struct example *skel;
    337  	int err = 0;
    338
    339  	skel = example__open();
    340  	if (!skel)
    341  		goto cleanup;
    342
    343  	skel->rodata->param1 = 128;
    344
    345  	err = example__load(skel);
    346  	if (err)
    347  		goto cleanup;
    348
    349  	err = example__attach(skel);
    350  	if (err)
    351  		goto cleanup;
    352
    353  	/* all libbpf APIs are usable */
    354  	printf("my_map name: %s\n", bpf_map__name(skel->maps.my_map));
    355  	printf("sys_enter prog FD: %d\n",
    356  	       bpf_program__fd(skel->progs.handle_sys_enter));
    357
    358  	/* detach and re-attach sys_exit program */
    359  	bpf_link__destroy(skel->links.handle_sys_exit);
    360  	skel->links.handle_sys_exit =
    361  		bpf_program__attach(skel->progs.handle_sys_exit);
    362
    363  	printf("my_static_var: %ld\n",
    364  	       skel->bss->handle_sys_enter_my_static_var);
    365
    366  cleanup:
    367  	example__destroy(skel);
    368  	return err;
    369  }
    370
    371**# ./example**
    372
    373::
    374
    375  my_map name: my_map
    376  sys_enter prog FD: 8
    377  my_static_var: 7
    378
    379This is a stripped-out version of skeleton generated for above example code.
    380
    381min_core_btf
    382------------
    383
    384**$ bpftool btf dump file 5.4.0-example.btf format raw**
    385
    386::
    387
    388  [1] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
    389  [2] CONST '(anon)' type_id=1
    390  [3] VOLATILE '(anon)' type_id=1
    391  [4] ARRAY '(anon)' type_id=1 index_type_id=21 nr_elems=2
    392  [5] PTR '(anon)' type_id=8
    393  [6] CONST '(anon)' type_id=5
    394  [7] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
    395  [8] CONST '(anon)' type_id=7
    396  [9] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
    397  <long output>
    398
    399**$ bpftool btf dump file one.bpf.o format raw**
    400
    401::
    402
    403  [1] PTR '(anon)' type_id=2
    404  [2] STRUCT 'trace_event_raw_sys_enter' size=64 vlen=4
    405        'ent' type_id=3 bits_offset=0
    406        'id' type_id=7 bits_offset=64
    407        'args' type_id=9 bits_offset=128
    408        '__data' type_id=12 bits_offset=512
    409  [3] STRUCT 'trace_entry' size=8 vlen=4
    410        'type' type_id=4 bits_offset=0
    411        'flags' type_id=5 bits_offset=16
    412        'preempt_count' type_id=5 bits_offset=24
    413  <long output>
    414
    415**$ bpftool gen min_core_btf 5.4.0-example.btf 5.4.0-smaller.btf one.bpf.o**
    416
    417**$ bpftool btf dump file 5.4.0-smaller.btf format raw**
    418
    419::
    420
    421  [1] TYPEDEF 'pid_t' type_id=6
    422  [2] STRUCT 'trace_event_raw_sys_enter' size=64 vlen=1
    423        'args' type_id=4 bits_offset=128
    424  [3] STRUCT 'task_struct' size=9216 vlen=2
    425        'pid' type_id=1 bits_offset=17920
    426        'real_parent' type_id=7 bits_offset=18048
    427  [4] ARRAY '(anon)' type_id=5 index_type_id=8 nr_elems=6
    428  [5] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
    429  [6] TYPEDEF '__kernel_pid_t' type_id=8
    430  [7] PTR '(anon)' type_id=3
    431  [8] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
    432  <end>
    433
    434Now, the "5.4.0-smaller.btf" file may be used by libbpf as an external BTF file
    435when loading the "one.bpf.o" object into the "5.4.0-example" kernel. Note that
    436the generated BTF file won't allow other eBPF objects to be loaded, just the
    437ones given to min_core_btf.
    438
    439::
    440
    441  LIBBPF_OPTS(bpf_object_open_opts, opts, .btf_custom_path = "5.4.0-smaller.btf");
    442  struct bpf_object *obj;
    443
    444  obj = bpf_object__open_file("one.bpf.o", &opts);
    445
    446  ...