bpf: Handle raw tracepoint arguments

[vadorovsky]

Provide an arg() method in RawTracepointArgs wrapper of bpf_raw_tracepoint_args and also in RawTracepointContext, so it's directly available in raw tracepoint programs.

The methods and traits implemented here are unsafe. There is no way to reliably check the number of available arguments, so requesting a non-existing one leads to undefined behavior.

---

This change is 

[netlify]

✅ Deploy Preview for aya-rs-docs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	ecb46b3
🔍 Latest deploy log	https://app.netlify.com/sites/aya-rs-docs/deploys/674cd4d17c9f6600082eaf7d
😎 Deploy Preview	https://deploy-preview-805--aya-rs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mergify]

@vadorovsky, this pull request is now in conflict and requires a rebase.

[tamird]

LGTM though I don't know much about tracepoint.

Reviewed 9 of 9 files at r1, all commit messages.
Reviewable status: all files reviewed, 7 unresolved discussions (waiting on @alessandrod and @vadorovsky)

---

bpf/aya-bpf/src/args.rs line 333 at r1 (raw file):

impl RawTracepointArgs {
    pub fn new(args: *mut bpf_raw_tracepoint_args) -> Self {

doc comment?

---

bpf/aya-bpf/src/args.rs line 344 at r1 (raw file):

    /// about the structure of the `bpf_raw_tracepoint_args` type. The tracepoint arguments are
    /// represented as an array of `__u64` values (i.e., `__u64 args[0]`), and this method
    /// provides a way to access these arguments conveniently in Rust using `as_slice`.

here and everywhere, can you link to the specific method using [`path::to::as_slice`]? I'm struggling to understand what this is referring to.

EDIT: after some searching I see this is a wrapper in the generated bindings. it would be good to state that

---

bpf/aya-bpf/src/args.rs line 346 at r1 (raw file):

    /// provides a way to access these arguments conveniently in Rust using `as_slice`.
    ///
    /// However, the method does not check the total number of available arguments for a given

can you rephrase this to say that such a check is not possible? this may lead the reader to believe an improvement is possible

---

test/integration-ebpf/src/raw_tracepoint.rs line 18 at r1 (raw file):

    pub common_type: u16,
    pub common_flags: u8,
    _padding: u8,

i think an earlier version of this PR had this in a common crate, is there a reason you went away from that?

---

test/integration-test/src/tests/raw_tracepoint.rs line 8 at r1 (raw file):

    pub common_type: u16,
    pub common_flags: u8,
    _padding: u8,

how come this is needed manually?

---

test/integration-test/src/tests/raw_tracepoint.rs line 20 at r1 (raw file):

    prog.attach("sys_enter").unwrap();

    let map: Array<_, SysEnterEvent> = Array::try_from(bpf.map_mut("RESULT").unwrap()).unwrap();

is the idea that this makes a syscall? how do you know that a syscall will have happened between here and the assertion below?

---

test/integration-test/src/tests/raw_tracepoint.rs line 21 at r1 (raw file):

    let map: Array<_, SysEnterEvent> = Array::try_from(bpf.map_mut("RESULT").unwrap()).unwrap();
    let result = map.get(&0, 0).unwrap();

nit: destructure?

[vadorovsky]

test/integration-test/src/tests/raw_tracepoint.rs line 20 at r1 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

is the idea that this makes a syscall? how do you know that a syscall will have happened between here and the assertion below?

There is always some syscall going on in the given moment, but actually, I think I should make it more reliable.

I can try writing a PID of the current process into a static variable and then using some syscall here, in the user-space test, then explicitly expect it in the program and then write to a map.

[vadorovsky]

test/integration-test/src/tests/raw_tracepoint.rs line 8 at r1 (raw file):

Previously, tamird (Tamir Duberstein) wrote…

how come this is needed manually?

Because BPF verifier is expecting all the memory used to be initialized. When Rust compiler adds extra bytes for alignment, those extra bytes are uninitialized, which often triggers verifier errors. See (ctrl+f "Alignment, padding and verifier errors"):

https://deploy-preview-93--aya-rs.netlify.app/book/start/getting-data-to-user-space/#sharing-data

[tamird]

Reviewable status: all files reviewed, 7 unresolved discussions (waiting on @alessandrod and @vadorovsky)

---

test/integration-test/src/tests/raw_tracepoint.rs line 8 at r1 (raw file):

Previously, vadorovsky wrote…

Because BPF verifier is expecting all the memory used to be initialized. When Rust compiler adds extra bytes for alignment, those extra bytes are uninitialized, which often triggers verifier errors. See (ctrl+f "Alignment, padding and verifier errors"):

https://deploy-preview-93--aya-rs.netlify.app/book/start/getting-data-to-user-space/#sharing-data

Ack, can you leave a small comment?

---

test/integration-test/src/tests/raw_tracepoint.rs line 20 at r1 (raw file):

Previously, vadorovsky wrote…

There is always some syscall going on in the given moment, but actually, I think I should make it more reliable.

I can try writing a PID of the current process into a static variable and then using some syscall here, in the user-space test, then explicitly expect it in the program and then write to a map.

More reliable seems good.

[mergify]

@vadorovsky, this pull request is now in conflict and requires a rebase.

[mergify]

@vadorovsky, this pull request is now in conflict and requires a rebase.

[tamird]

Reviewed 1 of 9 files at r1, 5 of 5 files at r2, 1 of 1 files at r3, 11 of 13 files at r4, all commit messages.
Reviewable status: 11 of 13 files reviewed, 4 unresolved discussions (waiting on @alessandrod and @vadorovsky)

[tamird]

Reviewed 2 of 13 files at r4, 8 of 8 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @alessandrod and @vadorovsky)