Currently, SaBRe cannot be built if some test dependencies are not met (e.g. efibootmgr). These should be optional.

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.

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.

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 -fPICwhen it really should only be -fPIE.

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

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,

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.

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:

1. a recursive chicken and egg problem where we rewrite e.g. malloc and then sabre calls malloc, which is solved easily with our enter_plugin() and exit_plugin() plugin methods.
2. we need to swap TLS from the client to Sabre as we are executing Sabre code from the rewriter. This is also accommodated easily with load_sabre_tls() and load_client_tls().
3. The rewriter is not idempotent.

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.

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.
: )