Add Rust native symbolization library and C API wrapper #267
Conversation
christos68k
force-pushed
the
ck/symblib
branch
from
1f1e3bb to
74bd1c1
Compare
christos68k
changed the title
christos68k
force-pushed
the
ck/symblib
branch
from
74bd1c1 to
8ea9b7b
Compare
|
nit: Can we add |
This commit adds the Rust native symbolization framework that we developed at Elastic and now making available in OpenTelemetry as part of the ebpf-profiler project. We can use it to implement automatic on-target symbolization of native binaries (e.g. Go executables) but also to enable an OpenTelemetry bulk native symbol upload protocol. Co-authored-by: Joel Höner <[email protected]> Co-authored-by: Victor Michel <[email protected]> Co-authored-by: Florian Lehner <[email protected]> Co-authored-by: Tim Rühsen <[email protected]> Co-authored-by: Davide Girardi <[email protected]>
christos68k
force-pushed
the
ck/symblib
branch
from
b19f1ed to
9bec392
Compare
There was a problem hiding this comment.
LGTM! Thanks so much for going through the effort of open-sourcing it!
NOTE: This is the initial PR that introduces the Rust symbolization framework but does not resolve packaging and artifact questions. We may decide to split this out into a separate repository post-merge.
Yeah: it would be best to have this in a separate repo at some point, but I also understand that this simplifies the contribution / donation process, so temporarily having it here is fine with me.
| } | ||
| }; | ||
|
|
||
| eprintln!("Processing {:?}", &unit); |
There was a problem hiding this comment.
| eprintln!("Processing {:?}", &unit); | |
| debug!("Processing {:?}", &unit); |
| impl From<SymblibString> for Option<String> { | ||
| fn from(maybe_str: SymblibString) -> Self { | ||
| if maybe_str.0.is_null() { | ||
| None | ||
| } else { | ||
| let cstr = unsafe { CString::from_raw(maybe_str.0) }; | ||
| mem::forget(maybe_str); | ||
| Some(cstr.into_string().unwrap()) | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
| impl From<SymblibString> for Option<String> { | |
| fn from(maybe_str: SymblibString) -> Self { | |
| if maybe_str.0.is_null() { | |
| None | |
| } else { | |
| let cstr = unsafe { CString::from_raw(maybe_str.0) }; | |
| mem::forget(maybe_str); | |
| Some(cstr.into_string().unwrap()) | |
| } | |
| } | |
| } |
I think it is not used.
| /// every range found in the executable. The user_data pointer is passed to | ||
| /// the visitor untouched and may be NULL. | ||
| #[no_mangle] | ||
| pub unsafe extern "C" fn symblib_rangeextr( |
There was a problem hiding this comment.
I know this first iteration is not immediately intended to be used in the profiler itself, however since there are ideas/plans to do this in the future I will just dump my thougths.
This API is not very convenient to use for ontarget symbolization because paths will likely be relative to /proc/{pid}/root. Maybe we can add an extra argument rootfs so that resolving debugaltlink is resolved in the same root fs. Or maybe as an alternative we can create an alternative API accepting file descriptors, so that rust lib does not need to worry about rootfs at all.
|
|
||
| ## `symbfile` format | ||
| symbfile format | ||
| =============== | ||
|
|
||
| `symbfile` is our custom file format for efficiently storing large amounts of |
There was a problem hiding this comment.
please correct me if I'm wrong, but symbfile format seems not suitable for quick address => symbol lookups, only for storing/transfer. Are there any plans to opensource the lookup data structure for use?
| @@ -0,0 +1,145 @@ | |||
| // Copyright The OpenTelemetry Authors | |||
There was a problem hiding this comment.
I'm not sure if this file was hand written, but it may worth generating the header using cbindgen to be always in sync with rust code
| /// | ||
| /// Currently implemented using the Zydis library. | ||
| #[derive(Debug)] | ||
| pub struct Amd64InstrDecoder(zydis::Decoder); |
There was a problem hiding this comment.
Have you considered implementing small subset of the disassembler in a rust?
Asking because of security reasons. I would be cautious to run a disassembler written in C on potentially untrusted user data, especially if running as root during ontarget symbolization.
It would be nice at least to document somehow, that the amd64 retpad extractor is using C library for security visibility.
This PR adds the Rust native symbolization framework that we developed at Elastic and now making available in OpenTelemetry as part of the
ebpf-profilerproject. We can use it to implement automatic on-target symbolization of native binaries (e.g. Go executables) but also to enable an OTel bulk native symbol upload protocol that we (Profiling SIG) can come together and specify.Building through Cargo works and all tests are passing.
NOTE: This is the initial PR that introduces the Rust symbolization framework but does not resolve packaging and artifact questions. We may decide to split this out into a separate repository post-merge.