-
Notifications
You must be signed in to change notification settings - Fork 290
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
uretprobe latest aya version cannot pass anymore ctx.ret().unwrap to bpf_probe_read #1062
Comments
Your panic handler is a lie: My guess is that your |
Thanks for the hint on the panic handler (I indeed took it long time ago from a example in the repository and did not think about it much). I will update it to get something more meaningful! |
Hmm when changing the panic handler to an infinite loop none of the probes works (even those that were working before)
I took the panic handler btw. from https://github.com/aya-rs/book/blob/main/examples/kprobetcp/kprobetcp-ebpf/src/main.rs#L68 |
Ok by using some debug logging I can confirm this is really related to
if I do not provide a variable, but a hardcoded value it works
I am really not sure why this happens. Any idea would be great. Will try to update aya again (just did it 2 days ago) - based on the latest in main. |
just don't |
I sent aya-rs/book#173 so other people don't use nonsense panic handlers. |
Thanks. I tried
Still the same error. However, I may lack some knowledge here to understand the issue. It used to work on a previous aya version. It works with local variables which is strange ret_value_len is a local variable. I can print it out via warn!() and it contains the correct value. Kernel version is 6.11.3-1 |
No unwrapping/panicing in ebpf code. You must handle all errors. |
I changed panic and removed all unwrap. I updated to the latest aya. Still the same error - see below.
then it works without issues. It seems only the interplay ctx.ret() and bpf_probe_read_user is an issue. However, if I do log the value of ctx.ret() it shows correctly number.
|
You seem not to understand the purpose of the verifier. Your problem comes from the fact that the verifier cannot prove that your code is safe. Just because you are able to log the value and see something sensible doesn't mean it is always sensible, and it also doesn't mean the verifier can prove it. Please don't post huge dumps of eBPF assembly. It isn't clear to me what you expect the volunteer maintainers of this project to do with that. |
Ok, thanks for your time. I assume then we can close the issue as this does not seem to be aya related. |
Rust: 1.84.0-nightly
Aya-ebpf: main#240291ab8121939515275b0b41df0439761e1a3c
Context: https://github.com/ZuInnoTe/rust-ebpf-localnet-kernel-filter-study/blob/main/uprobe-libcall-filter/uprobe-libcall-filter-ebpf/src/main.rs#L110
I try essentially to do the following:
This fails with
This used to work before, but I am not sure if it is due to a Rust nightly update or an Aya update.
Interestingly enough if I hardcode the number that is in ctx.ret().unwrap() (I verified that indeed it is the same number), e.g.
then the program runs without issues.
Any ideas what could be the reason?
The text was updated successfully, but these errors were encountered: