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>
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
* use the hdr_len of BTF.ext sections rather than size of struct
Otherwise this will erroneously fail on older btf_ext_header that have
less fields than the bindgen'd struct
* do not attempt to load a BTF object that has no types
* add tests
* fix: hdr_len i32 -> u32
* guard against a bigger header in the future
* use separate unsafe blocks
* simplify writing to zero'd out header
* merge safe block and address typo
Fix map creation failure when a BPF have a data section on older
kernel. (< 5.2)
If the BPF uses that section, relocation will fail accordingly and
report an error.
Remove mem::forget::<HashMap>() calls in tests which fail to compile when
HashMap is provided by hashbrown:
info: running `cargo check --all-targets --no-default-features` on aya-obj (11/23)
Checking aya-obj v0.1.0 (/home/tamird/src/aya/aya-obj)
error[E0505]: cannot move out of `map` because it is borrowed
--> aya-obj/src/relocation.rs:594:21
|
578 | let map = fake_legacy_map(1);
| --- binding `map` declared here
579 | let maps_by_symbol = HashMap::from([(1, ("test_map", Some(1), &map))]);
| ---- borrow of `map` occurs here
...
594 | mem::forget(map);
| ^^^ move out of `map` occurs here
595 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_1` because it is borrowed
--> aya-obj/src/relocation.rs:655:21
|
632 | let map_1 = fake_legacy_map(1);
| ----- binding `map_1` declared here
...
635 | (1, ("test_map_1", Some(1), &map_1)),
| ------ borrow of `map_1` occurs here
...
655 | mem::forget(map_1);
| ^^^^^ move out of `map_1` occurs here
656 | mem::forget(map_2);
657 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_2` because it is borrowed
--> aya-obj/src/relocation.rs:656:21
|
633 | let map_2 = fake_legacy_map(2);
| ----- binding `map_2` declared here
...
636 | (2, ("test_map_2", Some(2), &map_2)),
| ------ borrow of `map_2` occurs here
...
656 | mem::forget(map_2);
| ^^^^^ move out of `map_2` occurs here
657 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map` because it is borrowed
--> aya-obj/src/relocation.rs:694:21
|
678 | let map = fake_btf_map(1);
| --- binding `map` declared here
679 | let maps_by_symbol = HashMap::from([(1, ("test_map", Some(1), &map))]);
| ---- borrow of `map` occurs here
...
694 | mem::forget(map);
| ^^^ move out of `map` occurs here
695 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_1` because it is borrowed
--> aya-obj/src/relocation.rs:755:21
|
732 | let map_1 = fake_btf_map(1);
| ----- binding `map_1` declared here
...
735 | (1, ("test_map_1", Some(1), &map_1)),
| ------ borrow of `map_1` occurs here
...
755 | mem::forget(map_1);
| ^^^^^ move out of `map_1` occurs here
756 | mem::forget(map_2);
757 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
error[E0505]: cannot move out of `map_2` because it is borrowed
--> aya-obj/src/relocation.rs:756:21
|
733 | let map_2 = fake_btf_map(2);
| ----- binding `map_2` declared here
...
736 | (2, ("test_map_2", Some(2), &map_2)),
| ------ borrow of `map_2` occurs here
...
756 | mem::forget(map_2);
| ^^^^^ move out of `map_2` occurs here
757 | }
| - borrow might be used here, when `maps_by_symbol` is dropped and runs the destructor for type `hashbrown::HashMap<usize, (&str, Option<i32>, &maps::Map)>`
For more information about this error, try `rustc --explain E0505`.
error: could not compile `aya-obj` due to 6 previous errors
warning: build failed, waiting for other jobs to finish...
error: process didn't exit successfully: `/home/tamird/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo check --all-targets --manifest-path aya-obj/Cargo.toml --no-default-features` (exit status: 101)
This fixes `cargo build --all-features` by sidestepping the feature
unification problem described in The Cargo Book[0].
Add `cargo hack --feature-powerset` to CI to enforce that this doesn't
regress (and that all combinations of features work).
Since error_in_core is nightly-only, use core-error and a fake std
module to allow aya-obj to build without std on stable.
[0] https://doc.rust-lang.org/cargo/reference/features.html#feature-unification
This fix the following issues:
- Previously the DATASEC name wasn't sanitized resulting on "Invalid
name" returned by old kernels.
- The newly created BTF struct had a size of 0 making old kernels refuse
it.
This was tested on Debian 10 with kernel 4.19.0-21.
Clearly split the code between `.maps`, `maps` and data maps (bss, data,
rodata). Sprinkle comments.
Remove MapKind which was effectively only needed since we used to have
one variant - BpfSectionKind::Data - to represent all data maps. Instead
add explicit BpfSectionKind::{Data, Rodata, Bss} variants and match on
those when we initialize maps.
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
This adds support for loading XDP programs that are multi-buffer
capable, which is signalled using the xdp.frags section name. When this
is set, we should set the BPF_F_XDP_HAS_FRAGS flag when loading the
program into the kernel.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Include all new map types which were included in the last libbpf update
(5d13fd5aca).
Fixes: cb28533e2f ("aya-obj: Update `BPF_MAP_TYPE_CGROUP_STORAGE` name to `BPF_MAP_TYPE_CGRP_STORAGE`")
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
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
- Set the version number of `aya-obj` to `0.1.0`.
- Update the description of the `aya-obj` crate.
- Add a section in README and rustdoc warning about the unstable API.
This commit adds documentation on how program names are parsed from
section names, as is used by `aya_obj::Object.programs` as HashMap keys,
and updates the examples into using program names.
The crate has few libstd dependencies. Since it should be platform-
independent in principle, making it no_std like the object crate would
seem reasonable.
However, the feature `error_in_core` is not yet stabilized, and the
thiserror crate currently offers no no_std support. When the feature
no_std is selected, we enable the `error_in_core` feature, switch to
thiserror-core and replace the HashMap with the one in hashbrown.
To split the crate into two, several changes were made:
1. Most `pub(crate)` are now `pub` to allow access from Aya;
2. Parts of BpfError are merged into, for example, RelocationError;
3. BTF part of Features is moved into the new crate;
4. `#![deny(missing_docs)]` is removed temporarily;
5. Some other code gets moved into the new crate, mainly:
- aya::{bpf_map_def, BtfMapDef, PinningType},
- aya::programs::{CgroupSock*AttachType},
The new crate is currenly allowing missing_docs. Member visibility
will be adjusted later to minimize exposure of implementation details.
Refs: #473
Aya::obj depends on bindgen generated files, and we start
by migrating bindgen generated files.
This commit adds the new aya-obj crate to the workplace
and migrates generated files into the crate. We use core
instead of std in an effort to make the final crate no_std.
Bindgen was run against libbpf v1.0.1.
Refs: #473