srg-imperial / sabre Goto Github PK
View Code? Open in Web Editor NEWLoad-time selective binary rewriting
License: Other
Load-time selective binary rewriting
License: Other
Hi,
Is it possible to call pthread_create, to create a thread inside a plugin?
I tried to follow old issues and forks, and it seems it could be done somehow (with some TLS magic).
Any pointer or example?
The thread does not need to be intercepted, only the client.
Regards,
I would like to know how to use gdb to debug the target program (test_sbrtrace_hello) that Sabre started,
i.e., ./sabre ./plugins/sbr-trace/libsbr-trace.so -- test_sbrtrace_hello
.
I followed what was mentioned in the README and loaded debug-tools/gdb-symbol-loader.py, but it did not work.
I wanted to debug the target program because I had encountered plugins in other scenarios that caused the target binary to crash, so I had to use gdb to debug and check.
The following is the entire process of my debugging, am I missing anything and what do I need to do about it?
test_sbrtrace_hello
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello World!\n");
return 0;
}
Let's execute the command, and see this:
./sabre ./plugins/sbr-trace/libsbr-trace.so -- test_sbrtrace_hello
Now let's use gdb to debug sabre:
gdb sabre
set args ./plugins/sbr-trace/libsbr-trace.so -- test_sbrtrace_hello
source ../debug-tools/gdb-symbol-loader.py
b main
r
Then next and next:
then next:
Finally, the target program runs and exits, and gdb cannot debug it.
Whether I am operating improperly, I hope to get your reply, thank you very much.
: )
Rewrite functions when the user plugin defines it is currently a no-op.
While we are passing the appropriate detour registration function to the plugin here: https://github.com/srg-imperial/SaBRe/blob/master/loader/premain.c#L96-L101 we still need to invoke the rewriter like we do here: https://github.com/srg-imperial/SaBRe/blob/master/loader/ld_sc_handler.c#L349
Unfortunately this is not a trivial change because invoking a function rewrite from within the plugin creates the following 3 problems:
enter_plugin()
and exit_plugin()
plugin methods.load_sabre_tls()
and load_client_tls()
.From all the issues above, number 3 is the real blocker and this require significant engineering effort to fix properly. We need to work on some accounting to keep track of the .so in memory and make sure we don't double patch stuff.
Currently, a plugin needs to link against the all the architecture dependent code to get the real_syscall
symbol, pulling in the entire loader, which is not ideal. Furthermore, this means the the loader needs to be compiled with -fPIC
when it really should only be -fPIE
.
When a signal action is attached from the plugin, it is not possible to properly locate symbols for functions in the client program in order to present the user with a backtrace for debugging purposes.
A minimal reproduction is given with this patch. This can be applied by the usual means using the patch utility from the top level of the SaBRe tree with the following command patch -p1 < sigsegv_repro.patch
To observe the unexpected behaviour, build the SaBRe tree normally. This will produce an additional subdirectory in the build tree under plugins/sigsegv-repro
. This contains two products, a shared object plugin for SaBRe that installs a signal handler for SIGSEGV
from within the plugin, the resulting shared object is libbacktrace-plugin.so
. The other build product is a small sample executable that triggers a segmentation fault by attempting to dereference the NULL
pointer with three levels of function call indirection to be able to observe a backtrace, this product is called backtrace-offender
. The command to observe the issue is ./sabre plugins/sigsegv-repro/libbacktrace-plugin.so plugins/sigsegv-repro/backtrace-offender
To be able to observe the expected behaviour of the signal handler, it needs to be installed from the sample executable backtrace-offender
. The build system provides a facility to conveniently enable this functionality by passing the -DHANDLER_IN_OFFENDER=ON
option to CMake when configuring the build system. You can run the same command as previously to observe a correct backtrace.
I think we can agree that the build system is quite messy and that we need some basic smoke tests to make sure that non of the "official" plugins don't randomly break.
I am quite happy to do the work to get this in, but would like to discuss what it is we want from the smoke tests. What I add in mind was to have build check for every platform we support (x86_64 and risc-v) and a simple run of all three plugins to check they work alright, maybe on ls as a start.
As far as the build system goes, I would like to create a CMake function for creating a plugin that sets up all the relevant options automatically based on the build type as well as cleaning up a bit loader/CMakeLists.txt.
If people are OK with this proposal I will go ahead and make a patch.
I am trying to get ./sabre plugins/sbr-trace/libsbr-trace.so -- /bin/ls
to work on Arch Linux. I am getting this error:
sabre: /home/notiurii/Uni/UROP2/SaBRe/loader/rewriter.c:562: find_ld_symbol: Assertion `false && "We couldn't find ld symbols"' failed.
fish: Job 1, './sabre plugins/sbr-trace/libsb…' terminated by signal SIGABRT (Abort)
How do I approach this issue? See full log at https://www.toptal.com/developers/hastebin/conexaqoku.log
For example
/sabre ./plugins/sbr-trace/libsbr-trace.so -- test_sbrtrace_hello.
What should we do to debug libsbr-trace.so intercept and replace system calls in gdb? For example, the program executes the write system call, and the plugin prints out some log messages before executing write.
Even though I used gdb to debug sabre, gdb was never able to intercept and view the code function in the dynamic link library libsbr-trace.so that rewrites the system call.
Understanding this process is very important for writing new plugins, can you answer and explain this process, thanks.
Currently, SaBRe cannot be built if some test dependencies are not met (e.g. efibootmgr
). These should be optional.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.