This change does a few things:
- it fixes a bug in the wrappers, where we were expecting the kernel to
return len=1 for b"\0" where it instead returns 0 and doesn't write
out the NULL terminator
- it makes the helpers more robust by hardcoding bound checks in
assembly so that LLVM optimizations can't transform the checks in a
way that the verifier can't understand.
- it adds integration tests
This commit adds a new probe for bpf_attach_cookie, which would be used
to implement USDT probes. Since USDT probes aren't currently supported,
we this triggers a dead_code warning in clippy.
There are cases where exposing FEATURES - our lazy static - is actually
helpful to users of the library. For example, they may wish to choose to
load a different version of their bytecode based on current features.
Or, in the case of an orchestrator like bpfd, we might want to allow
users to describe which features their program needs and return nice
error message is one or more nodes in their cluster doesn't support the
necessary feature set.
To do this without breaking the API, we make all the internal members of
the `Features` and `BtfFeatures` structs private, and add accessors for
them. We then add a `features()` API to avoid leaking the
lazy_static.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Based on the discussion in Discord we've decided to drop the
iter_key() API for LPM Trie. According to the kernel self-tests and
experimentation done in Aya, providing a key into bpf_map_get_next_id
will either:
- If key is an EXACT match, proceed iterating through all keys in the
trie from this point
- If key is NOT an EXACT match, proceed iterating through all keys in
the trie starting at the leftmost entry.
An API in Aya could be crafted that gets the LPM match + less specific
matches for a prefix using these semantics BUT it would only apply to
userspace. Therefore we've opted out of fixing this.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Move BpfError::UnsupportedMap into MapError and add a map_type field to
the error.
Update the `allow_unsupported_maps` function comment.
Update the logic to check if any unsupported maps are being used. More
specifically only search a program's maps if `allow_unsupported_maps` is
set and then use the iter function `try_for_each` with a match statement
which allows us to return the inner map type if it's unsupported.
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
Just because aya doesn't support working with some map
types doesn't mean we should't allow them to be loaded.
Add a new `Unsupported` map type to facilitate this,
Next add a user configurable option `allow_unsupported_maps()`
which can be called against the `bpfLoader`. Additionally
add a nice warning log message when a program is being loaded
by Aya and contains an unsupported map type.
Signed-off-by: Andrew Stoycos <astoycos@redhat.com>
This patch introduces `pt_regs` handling in aya-bpf/args.rs
for the riscv64 architecture. The current CI is disabled
for riscv64 because this implementation is missing.
These two functions are needed because kernel symbols representing
syscalls have architecture-specific prefixes.
These are the equivalent of bcc's get_syscall_fnname and
get_syscall_prefix.
Solves: #534
Before this change:
```
error[E0382]: use of moved value: `no_copy`
--> test/integration-ebpf/src/log.rs:35:9
|
33 | let no_copy = NoCopy {};
| ------- move occurs because `no_copy` has type `NoCopy`, which does not implement the `Copy` trait
34 |
35 | debug!(&ctx, "{:x}", no_copy.consume());
| ^^^^^^^^^^^^^^^^^^^^^-------^---------^
| | | |
| | | `no_copy` moved due to this method call
| | use occurs due to use in closure
| value used here after move
|
note: `NoCopy::consume` takes ownership of the receiver `self`, which moves `no_copy`
--> test/integration-ebpf/src/log.rs:28:24
|
28 | fn consume(self) -> u64 {
| ^^^^
= note: this error originates in the macro `debug` (in Nightly builds, run with -Z macro-backtrace for more info)
For more information about this error, try `rustc --explain E0382`.
error: could not compile `integration-ebpf` (bin "log") due to previous error
```
This fix aya wrong logic causing non entrypoint functions to not have
any BTF relocations working.
Also fix missing section_offset computation for instruction offset in
multiple spots.
Files changed:
M aya-obj/src/generated/btf_internal_bindings.rs
M aya-obj/src/generated/linux_bindings_aarch64.rs
M aya-obj/src/generated/linux_bindings_armv7.rs
M aya-obj/src/generated/linux_bindings_riscv64.rs
M aya-obj/src/generated/linux_bindings_x86_64.rs
M bpf/aya-bpf-bindings/src/aarch64/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
aya-log-ebpf-macros was failing to compile because it was referencing
a couple of `DisplayHint` variants that no longer exist. These were
removed in #599.
```
Compiling aya-log-ebpf-macros v0.1.0 (/home/robert/aya/aya-log-ebpf-macros)
error[E0599]: no variant or associated item named `Ipv4` found for enum `DisplayHint` in the current scope
--> aya-log-ebpf-macros/src/expand.rs:93:22
|
93 | DisplayHint::Ipv4 => parse_str("::aya_log_ebpf::macro_support::check_impl_ipv4"),
| ^^^^ variant or associated item not found in `DisplayHint`
error[E0599]: no variant or associated item named `Ipv6` found for enum `DisplayHint` in the current scope
--> aya-log-ebpf-macros/src/expand.rs:94:22
|
94 | DisplayHint::Ipv6 => parse_str("::aya_log_ebpf::macro_support::check_impl_ipv6"),
| ^^^^ variant or associated item not found in `DisplayHint`
For more information about this error, try `rustc --explain E0599`.
```
Tamir Duberstein
Mary
Alessandro Decina
Dave Tucker
ajwerner
Mary
Andrew Stoycos
dependabot[bot]
Kenjiro Nakayama
Federico Ponzi
Alexis (Poliorcetics) Bourget
alessandrod
Robert Bartlensky