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
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`.
```
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
Files changed:
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/aarch64/helpers.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/helpers.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/helpers.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/helpers.rs
Such an assignment in two parts (first deref in `unsafe`, then field
access outside of `unsafe`) is bogus: the deref "returned" by the
`unsafe` block actually creates a copy of the `__sk_buff` struct because
it implements `Copy`. The mark value is written to the `mark` field of
the copy, and not the real `__sk_buff`.
Change it to do it all in the `unsafe` block.
The same is done for the `.len()` getter to avoid copying the whole
`__sk_buff` struct for a 32 bit field. Although such a copy should be
optimized out by the compiler, it's better to help it do so.
Kernel 4.15 added a new eBPF program that can
be used with cgroup v2 to control & observe device
access (e.g. read, write, mknod) - `BPF_PROG_TYPE_CGROUP_DEVICE`.
We add the ability to create these programs with the `cgroup_device`
proc macro which creates the `cgroup/dev` link section. Device
details are available to the eBPF program in `DeviceContext`.
The userspace representation is provided with the `CgroupDevice`
structure.
Fixes: #212
Signed-off-by: Milan <milan@mdaverde.com>
Files changed:\nM aya/src/generated/btf_internal_bindings.rs
M aya/src/generated/linux_bindings_aarch64.rs
M aya/src/generated/linux_bindings_armv7.rs
M aya/src/generated/linux_bindings_riscv64.rs
M aya/src/generated/linux_bindings_x86_64.rs
M bpf/aya-bpf-bindings/src/aarch64/bindings.rs
M bpf/aya-bpf-bindings/src/aarch64/helpers.rs
M bpf/aya-bpf-bindings/src/armv7/bindings.rs
M bpf/aya-bpf-bindings/src/armv7/helpers.rs
M bpf/aya-bpf-bindings/src/riscv64/bindings.rs
M bpf/aya-bpf-bindings/src/riscv64/helpers.rs
M bpf/aya-bpf-bindings/src/x86_64/bindings.rs
M bpf/aya-bpf-bindings/src/x86_64/helpers.rs
This change separates the previous `SkBuffContext` into three structs:
* `SkBuff` which is a wrapper around `__sk_buff` which contains all
possible methods operating on it.
* `SkBuffContext` which is a program context for programs which
**cannot** access `__sk_buff` directly and instead can only use
`load_bytes`.
* `TcContext` which is a classifier context which can access `__sk_buff`
directly, hence exposes `data` and `data_end`.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
This change adds optional display hints:
* `{:x}`, `{:X}` - for hex representation of numbers
* `{:ipv4}`, `{:IPv4}` - for IPv4 addresses
* `{:ipv6}`, `{:IPv6}` - for IPv6 addresses
It also gets rid of dyn-fmt and instead comes with our own parser
implementation.
Tested on: https://github.com/vadorovsky/aya-examples/tree/main/tc
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
The pull_data method is used to ensure that all the required bytes
are available in the linear portion of the skb.
Signed-off-by: Hengqi Chen <chenhengqi@outlook.com>
This commit moves the aya-log projects from the subtree and adds them to
the main cargo workspace. It also brings the BPF crates into the
workspace and moves the macro crates up a level since they aren't BPF
code.
Miri was disabled for aya-bpf as the previous config wasn't actually
checking anything.
CI, clippy, fmt and release configurations have all been adjusted
appropriately.
CI was not properly running for other supported arches which was also
ixed here.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
The `bpf_printk!` macro is a helper providing a convenient way to invoke the
`bpf_trace_printk` and `bpf_trace_vprintk` BPF helpers. It is implemented as
a macro because it requires variadic arguments.
Change it from `[i8; 16]` to `[u8; 18]`. `i8` arrays cannot be easily used in
Rust for converting to string (i.e. with `core::str::from_utf8_unchecked`)
and developers have to convert them themselves with unsafe code.
Using u8 arrays lets developers to just convert it with
`core::str::from_utf8_unchecked` without any limitations.
Example:
https://github.com/vadorovsky/aya-examples/blob/main/clone/clone-ebpf/src/main.rs
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
This commit replaces the existing RTF test runner with a simple rust
binary package called - integration-test.
integration-test depends on integration-ebpf, which contains test eBPF
code written in Rust and C. `cargo xtask build-integration-test-ebpf`
can be used to build this code and supress rust-analyzer warnings. It
does require `bpf-linker`, but that is highly likely to be available to
developers of Aya. It also requires a checkout of `libbpf` to extract
headers like bpf-helpers.h.
Since everything is compiled into a single binary, it can be run
be run locally using `cargo xtask integration-test` or remotely using
`./run.sh` which re-uses the bash script from the old test framework
to spawn a VM in which to run the tests.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This change adds two new helpers:
* bpf_probe_read_user_str_bytes
* bpf_probe_read_kernel_str_bytes
Those new helpers are returning a bytes slice (`&[u8]`) with a length
equal to the length of probed, null-terminated string. When using those
helpers, users don't have to manually check for length and create such
slices themselves. They also make converting to `str` way more
convenient, for example:
```rust
let my_str = unsafe {
core::str::from_utf8_unchecked(
bpf_probe_read_user_str_bytes(user_ptr, &mut buf)?
)
};
```
This change also deprecates the old helpers, since their names are
confusing (they have nothing to do with Rust `str`) and using them
requires writing boilerplate code (for checking the length and making
eBPF verifier happy):
* bpf_probe_read_user_str
* bpf_probe_read_kernel_str
Tested on:
516b29af68
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
As it turns out, the verifier gets upset if you try to read the values
directly without using bpf_probe_read.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>