derek/bachelor-thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fixes from Niklas, Johannes, Hendrik

Browse Source
This commit is contained in:
Derek Christ
2022-08-05 10:54:38 +02:00
parent 98add62119
commit 27ec50fab7
8 changed files with 48 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
inc/2.dynamorio.tex
View File

@@ -17,7 +17,7 @@ However, those context switches result in a significant performance penalty as t
DBI tools can either invoke the target application by themselfes or are attached to the application's process dynamically.
The former method allows instrumentation of even the early startup stage of the application whereas the latter method might be used if the application has to be first brought into a certain state or the process cannot be restarted due to reliability reasons.
Some DBI tools also allow to directly implement the DBI framework into the applications source code.
While this removes the flexibility of observing applications that are only available in binary form, it enables the control over the DBI tool using its application interface.
While this eliminates the flexibility of observing applications that are only available in binary form, it enables the control over the DBI tool using its application interface.
With this method, it is possible to precisely instrument only a specific code region of interest and otherwise disable the tool for performance reasons.
In all cases, the instrumentation tool executes in the same process and address space as the target application.
@@ -53,7 +53,7 @@ A basic block is a sequence of instructions extracted from the target applicatio
In the code cache, the instrumentation instructions will directly be inserted.
To be able to execute the modified code, basic blocks in the code cache are extended by two \textit{exit stubs}, ensuring that at the end the control is transferred back to DynamoRIO via a context switch.
From there the applications and processor state is saved and the next basic block will be copied into the code cache, modified and executed after restoring the previously saved state.
From there the application's and processor's state is saved and the next basic block is copied into the code cache, modified and executed after restoring the previously saved state.
Basic blocks that are already located in the code cache are directly executed without copying, however, a context switch is still needed to determine the next basic block to execute.
To reduce this overhead and avoid a context switch, DynamoRIO can \textit{link} two basic blocks together that were targeted by a direct branch, i.e., branches whose target address will not change during runtime.
@@ -71,13 +71,13 @@ The application code is loaded by the dispatcher, modified by the basic block bu
\begin{figure}
\begin{center}
\tikzfig{img/dynamorio}
\caption{DynamoRIO runtime code manipulation layer \cite{Bruening2004}.}
\caption[DynamoRIO runtime code manipulation layer.]{DynamoRIO runtime code manipulation layer \cite{Bruening2004}.}
\label{fig:dynamorio}
\end{center}
\end{figure}
As mentioned in Section \ref{sec:dbi}, it is important for a DBI tool to operate transparently.
DynamoRIO takes a number of measures to achieve this goal, some of which will now be explained \cite{Bruening2004}.
DynamoRIO takes a number of measures to achieve this goal, some of which are now explained \cite{Bruening2004}.
As sharing libraries with the target application can cause transparency issues, especially when using non-reentrant routines or routines that alter static state such as error codes, DynamoRIO directly interfaces with the system using system calls and even avoids to use the C standard library (e.g., \textit{glibc} on Linux).
The same should also apply for user-written instrumentation clients (introduced in more detail in Section \ref{sec:dynamorio_client}), but the direct usage of system calls is discouraged as this bypasses the internal monitoring of DynamoRIO for changes that affect the processes address space.
Instead, DynamoRIO provides a cross-platform API for generic routines as file system operations and memory allocation.
@@ -103,7 +103,7 @@ DynamoRIO provides a programming interface to develop external so-called \textit
Clients are user-written instrumentation tools and make it possible to dynamically modify the basic blocks, either to alter the application behavior or to insert observational instructions.
A DynamoRIO client is compiled into a shared library and passed to the \textit{drrun} utility using a command line option.
Clients implement a number of hook functions that will be called by DynamoRIO for certain events such as the creation of a basic block or of a trace.
Generally, there are two classes of hooks: those that execute on basic block creation instrument all of the application code and those that execute on trace generation are only interested in frequently executed code.
Generally, there are two classes of hooks: those that execute on basic block creation, which instrument all of the application code, and those that execute on trace generation, which are only interested in frequently executed code.
It is important to note that the hooks for basic block and trace generation are not called every time when this code sequence is executed, but only when these basic blocks are generated and placed into the code cache.
So the required instructions have to be inserted into the basic block instruction stream in this stage, rather than implementing the observational or manipulative behavior in the hook function itself.