.eh_frame to bpf compiler

[dvc94ch]

Hi,

I came accross your research paper, and was wondering if you had any thoughts on building a .eh_frame to bpf compiler and how hard you think it would be. I would like to unwind the stack in a linux bpf program that doesn't have frame pointers enabled.

[dvc94ch]

So I ported this to rust and hit the 512byte stack size limit :/ Looks like the kernel needs support for unwinding based on .eh_elf files.

• [0] https://github.com/dvc94ch/ehframe-bpf-compiler

[tobast]

Hi,

I'm not familiar with bpf, but if I understand your second comment correctly, indeed, the .eh_elf is absolutely not standard and you'll need support for this — although it's basically a shared library providing a single symbol that you can call with the right parameters and will return a C structure with unwound registers.

[dvc94ch]

Are you familiar with the new kernel based orc unwinder? It currently only works for unwinding kernel code. It might be easier to extend the support for orc unwinding to user space instead of adding a new unwinder based on .eh_elf. I'll try that next weekend, see if I can get something working.

[francesco-zappa-nardelli]

Hi David can you give use more information about your project and your goal? I am afraid none of us is familiar with bpf. We have several tools to manipulate unwind information (including eg a .orc -> .eh_frame translator) and perhaps we can help. Best Francesco

…

On 1 Feb 2021, at 11:01, David Craven ***@***.***> wrote: Are you familiar with the new kernel based orc unwinder? It currently only works for unwinding kernel code. It might be easier to extend the support for orc unwinding to user space instead of adding a new unwinder based on .eh_elf. I'll try that next weekend, see if I can get something working. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4JSXZZXV3HE3EDVX4ODHTS4Z3WFANCNFSM4WZQERNA>.

[tobast]

To be honest this project is getting a bit old in my memory and I don't have every single detail in mind anymore, but I remember looking into orc. From what I remember, it just didn't have the expressiveness I needed to transcribe the .eh_frame (IIRC it was actually part of the point of orc — having something way simpler that satisfies kernel usecases).

[dvc94ch]

Well the berkeley packet filter is a vm for code running inside of the kernel. You can build interesting tools for monitoring and analysing programs using this vm. One example (not the most interesting one) is instead of copying the entire stack into user space, like perf does and unwinding the stack there, you can unwind and count the stack traces in the kernel and only copy the stack trace to user space.

The first approach was to try to compile the .eh_frame section into a bpf program that unwinds the stack inside of the kernel. However the resulting program is too big for bpf. So now I'm trying to figure out how to best teach the kernel to unwind the stack, so the bpf_get_stack function can unwind the stack in the absence of frame pointers.