This allows for `pin` to be called as `Xdp::pin()` or
Program::pin() - the same way that unload() can be used.
This simplifies the use of this API.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Kernels before 5.11 don't use cgroup accounting, so they might reach the
RLIMIT_MEMLOCK when creating maps. After this change, we raise a warning
recommending to raise the RLIMIT_MEMLOCK.
This removes the ProgramFd trait with a struct that wraps a RawFd.
Program::fd() has been implemented as well as fd() for each Program
Type. This allows for a better API than requiring the use of the
ProgramFd trait.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This allows access to XdpLink, XdpLinkId etc... which is currently
unavailable since these modules are private
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Remove LinkRef and remove the Rc<RefCell<_>> that was used to store
type-erased link values in ProgramData. Among other things, this allows
`Bpf` to be `Send`, which makes it easier to use it with async runtimes.
Change the link API to:
let link_id = prog.attach(...)?;
...
prog.detach(link_id)?;
Link ids are strongly typed, so it's impossible to eg:
let link_id = uprobe.attach(...)?;
xdp.detach(link_id);
As it would result in a compile time error.
Links are still stored inside ProgramData, and unless detached
explicitly, they are automatically detached when the parent program gets
dropped.
Currently errors can occur if the verifier output is > buffer as we get
ENOMEM. We should only provide a log_buf if initial load failed, then
retry up to 10 times to get full verifier output.
To DRY this logic it has been moved to a function so its shared with
program loading
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
one verifier loop to rule them all
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This requires loading the BTF to kernel when loading all programs as
well as implementing Extension program type
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
fentry and fexit programs are similar to kprobe and kretprobe, but they
are newer and they have practically zero overhead to call before or
after kernel function. Also, fexit programs are focused on access to
arguments rather than the return value.
Those kind of programs were introduced in the following patchset:
https://lwn.net/Articles/804112/
Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
Map and ProgramData objects had unnecessarily cloned strings for their
names, despite them being just as easily available to external users via
bpf.maps() and bpf.programs().
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.
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>
This commit adds 2 new methods to aya::sys
- bpf_pin_object
- bpf_get_object
Which allow the pinning and retrieval of programs/maps to bpffs.
It adds a `Program.pin` API, such that a loaded program can be pinned.
For map pinning, the user must ensure the `pinning u32` in the
`bpf_map_def` is set to 1, maps will be pinned using a new builder API.
BpfLoader::new().map_pin_path("/sys/fs/bpf/myapp").load_file("myapp.o")
This will pin all maps whose definition requests pinning to path + name.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>