When a BPF program doesn't specify the target kernel version, the
most compatible option is to set the program kernel version to match
the currently running kernel.
In kernel 4.15 and additional parameter was added to allow maps to have
names but using this breaks on older kernels.
This change makes it so the name is only added on kernels 4.15 and
newer.
This is necessary since the context is used in many other program types
and not just in SK_SKB programs.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This commit fixes name parsing of sk_skb sections such that both named
and unnamed variants will work correctly.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This patch adds some documentation to aya-bpf/helpers and adds documentation
for the module itself and for all of the wrappers currently defined in the module.
It also implements the rest of the bpf_probe_read_* wrappers that were missing from this
file. In the future, it probably also makes sense to add some bpf_probe_read_* wrappers
that can read directly into a map pointer, avoiding the BPF stack altogether. I'm going to
call this out of scope for this PR, but plan to submit a subsequent one that addresses
this use case.
Signed-off-by: William Findlay <william@williamfindlay.com>
Until we add another set of bpf_probe_read_* wrappers for reading into a map pointer,
users need access to the underlying bpf_probe_read helper, which is clobbered by this
module. This patch enables direct access to the underlying helpers::gen module to support
such use cases.
In my view, it would also probably make sense to just not export helpers::gen::* and force
the user to opt into helpers::gen, but this can be decided on later.
Signed-off-by: William Findlay <william@williamfindlay.com>
This change adds support for the following program types:
* raw tracepoint
* LSM
Supporting LSM programs involved a necessity of supporting more
load_attrs for the BPF_PROG_LOAD operation, concretely:
* expected_attach_type - for LSM programs, it has always to be set to
BPF_LSM_MAC
* attach_btf_obj_fd - it's often used to reference the file descriptor of
program's BTF info, altough in case of LSM programs, it only has to
contain the value 0, which means the vmlinux object file (usually
/sys/kernel/btf/vmlinux)
* attach_btf_id - ID of the BTF object, which in case of LSM programs is
the ID of the function (the LSM hook)
The example of LSM program using that functionality can be found here:
https://github.com/vadorovsky/aya-example-lsmFixes: #9
Signed-off-by: William Findlay <william@williamfindlay.com>
Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>