Program::attach_uprobe_with_opts() fails when building with --release

[0xB10C]

I've ran into an issue while deploying binary build with cargo build --release that attaches some uprobes to C++ functions. Locally, cargo build without --release, it works fine. To confirm the issue I've changed the libbpf CI to run with --release in 0xB10C@11b11f7.

From this run:

...
libbpf: prog 'bpf_usdt_arg': relo #1: patched insn #9 (LDX/ST/STX) off 128 -> 128
libbpf: prog 'bpf_usdt_cookie': relo #2: <byte_off> [39] struct pt_regs.ip (0:16 @ offset 128)
libbpf: prog 'bpf_usdt_cookie': relo #2: matching candidate #0 <byte_off> [172] struct pt_regs.ip (0:16 @ offset 128)
libbpf: prog 'bpf_usdt_cookie': relo #2: patched insn #4 (LDX/ST/STX) off 128 -> 128
libbpf: bpf_uprobe_opts has non-zero extra bytes
thread 'test_object_uprobe_with_cookie' panicked at 'Failed to attach prog: Internal("bpf call \"libbpf_rs::program::Program::attach_uprobe_with_opts<std::path::PathBuf>::{{closure}}\" returned NULL")', libbpf-rs/tests/test.rs:1160:10
stack backtrace:
   0: rust_begin_unwind
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
   1: core::panicking::panic_fmt
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1750:5
   3: core::ops::function::FnOnce::call_once
   4: core::ops::function::FnOnce::call_once
             at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I'm seeing the same issue with libbpf: bpf_uprobe_opts has non-zero extra bytes in my release builds. At the moment, I don't have any clue what could be causing this, yet.

[anakryiko]

libbpf-rs's initialization of libbpf's opts structs doesn't seem to do memset(0), which libbpf's LIBBPF_OPTS() macro does (see).

Unfortunately only since C23 it will be specified that C compiler has to zero-initialize paddings, so until then we have to keep making weird hacks like the one in LIBBPF_OPTS(). I actually don't know what is Rust's stance on this.

[danielocfb]

I actually don't know what is Rust's stance on this.

I haven't found an authoritative answer for repr(C) specifically, but in general the value of padding bytes is not guaranteed to be zero, is my understanding. Even std::mem::zeroed does not guarantee that, it appears:

This means that, for example, the padding byte in (u8, u16) is not necessarily zeroed.

It's not entirely clear to me whether MaybeUninit::zeroed would be suitable, but it seems to work. I opened rust-lang/rust#111608 for clarification.

[danielocfb]

What I am confused about currently is why we hit this issue to begin with: bindgen makes padding bytes explicit (e.g., __bindgen_padding_0 here), which means that ..Default::default() initialization will cover them. So it almost seems as if bindgen is missing a gap somewhere...

[danielocfb]

What I am confused about currently is why we hit this issue to begin with

And the answer is:

--- libbpf-rs/src/program.rs
+++ libbpf-rs/src/program.rs
@@ -545,7 +545,7 @@ impl Program {

         let func_name = util::str_to_cstring(&func_name)?;
         let opts = libbpf_sys::bpf_uprobe_opts {
-            sz: mem::size_of::<Self>() as u64,
+            sz: mem::size_of::<libbpf_sys::bpf_uprobe_opts>() as _,
             ref_ctr_offset: ref_ctr_offset as libbpf_sys::size_t,
             bpf_cookie: cookie,
             retprobe,