The log level implementation in b36cbc3eb8
was incomplete as the verifier could reject programs which exceeded
their instruction limits within logging statements. This commit
addresses this issue by making the log level static variable immutable
(s.t. the compiler puts it in a read-only section) and adds an
additional test which the verifier will reject as an infinite loop iff
it is unable to detect that the static variable would otherwise allow
the logging.
Working with aya in vscode will currently show a number of warnings
along the lines of:
```
found duplicate lang item `panic_impl`
the lang item is first defined in crate `std` (which `aya` depends on)
...
second definition in the local crate (`bpf_probe_read`)
```
This comes from feature unification.
integration-test requires the integration-common user feature, which
requires aya, which in turn brings in std.
For this same reason we avoid running clippy across the whole workspace.
We can avoid this issue by using the panic handler from the another
crate, which implements the same loop {} panic handler we use today.
It seems rustc is happy to conditionally link the panic handler
from an external crate without issuing warnings.
Therefore, we add our own crate - ebpf-panic - for this purpose.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
IP address types are available in `core`, so they can be used also in
eBPF programs. This change adds support of these types in aya-log.
* Add implementation of `WriteTuBuf` to these types.
* Support these types in `Ipv4Formatter` and `Ipv6Formatter`.
* Support them with `DisplayHint::Ip`.
* Add support for formatting `[u8; 4]`, to be able to handle
`Ipv4Addr::octets`.
Some of these functions fail to compile when not inlined, so we should
be explicit.
Before deciding on this approach I tried various ways of making all
these functions #[inline(never)] to save instructions but I ran into
blockers:
- These functions currently return Result, which is a structure. This is
not permitted in BPF.
- I tried inventing a newtype that is a #[repr(transparent)] wrapper of
u16, and having these functions return that; however it seems that
even if the object code is legal, the verifier will reject such
functions because the BTF (if present, and it was in my local
experiments) would indicate that the return is a structure.
- I tried having these functions return a plain u16 where 0 means error,
but the verifier still rejected the BTF because the receiver (even if
made into &self) is considered a structure, and forbidden.
We can eventually overcome these problems by "lying" in our BTF once
support for it matures in the bpf-linker repo (e.g. Option<NonZeroU16>
should be perfectly legal as it is guaranteed to be word-sized), but we
aren't there yet, and this is the safest thing we can do for now.
Replace all `assert!(matches!(..))` with `assert_matches!(..)`.
Remove the now-unused build-integration-test xtask command whose logic
doesn't match that of the build-and-run command.
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
```
Having separate format hints and tokens per IP address family is
unnecessary, since they are represented by different types and we handle
format hints for each type separately. So we can just have one format
hint.
Also, we should be consistent with the format strings grammar in
Rust[0]. The `type` token, which is mapped to formatting traits, usually
consists of one letter[1] (and optional `?` for `Debug` trait, but that
doesn't matter for us). It shouldn't consist of multiple letters. Our
`:ipv4` and `:ipv6` tokens were clearly breaking that convention, so we
should rather switch to something with one letter - hence `:i`.
[0] https://doc.rust-lang.org/std/fmt/#syntax
[1] https://doc.rust-lang.org/std/fmt/#formatting-traits
Christian A. Jacobsen
Tamir Duberstein
Addison Crump
Dave Tucker
Michal Rostecki
Alessandro Decina