thesis: Apply proofreading suggestions
This commit is contained in:
@@ -56,8 +56,7 @@ exit_group(0) = ?
|
||||
\label{lst:strace}
|
||||
\end{listing}
|
||||
|
||||
This approach works great for debugging and other use-cases,
|
||||
but only intercepting system calls does not statisfy the requirements for this work.
|
||||
This approach works well for debugging and other use cases, but intercepting system calls alone does not satisfy the requirements of this work.
|
||||
|
||||
|
||||
\subsection{\texttt{ltrace} Command}\label{subsec:ltrace}
|
||||
@@ -210,7 +209,7 @@ The function \texttt{dlsym} is used to retrieve the original address of the \tex
|
||||
\cite{dlsym.3}
|
||||
|
||||
By using this method, it is possible to override, and therefore wrap, any function as long as the targeted binary was not statically linked.
|
||||
Although, one has to be aware that not only function calls inside the targeted binary, but also calls inside other libraries (e.g., to \texttt{malloc}) are redirected to the overriding function.
|
||||
However, one must be aware that not only function calls inside the targeted binary, but also calls inside other libraries (e.g., \texttt{malloc}) are redirected to the overriding function.
|
||||
|
||||
|
||||
\subsection{Conclusion}\label{subsec:methods-for-intercepting-conclusion}
|
||||
@@ -260,7 +259,7 @@ It should always be possible to fully parse the recorded calls without any speci
|
||||
|
||||
\subsection{Numbers}\label{subsec:retrieving-numbers}
|
||||
|
||||
The most simple types of argument are plain numbers, like integers (\texttt{int}, \texttt{long}, \ldots) or floating point numbers (\texttt{float}, \texttt{double}).
|
||||
The simplest types of arguments are plain numbers, like integers (\texttt{int}, \texttt{long}, \ldots) or floating point numbers (\texttt{float}, \texttt{double}).
|
||||
(In fact, \textit{all} arguments are represented as numbers or integers.
|
||||
See the following subsections for examples.)
|
||||
Plain numbers may be formatted simply as what they are, in base 10 notation, or with a prefix like \texttt{0x} for hexadecimal or \texttt{0} for octal representation.
|
||||
@@ -284,7 +283,7 @@ Special values inside the string are escaped with a backslash.
|
||||
|
||||
Example: \texttt{sem\_unlink(0x1234:"/test-semaphore")}.
|
||||
|
||||
Another type of ``string'' in C is a buffer with a known length.
|
||||
Another type of string-like data in C is a buffer with a known length.
|
||||
When buffers are used, usually another argument is passed to the function which indicates the length of the buffer.
|
||||
This fact may be used to print out the contents of the buffer in the same way as normal C strings.
|
||||
|
||||
@@ -338,8 +337,8 @@ Example (\texttt{malloc}): \\
|
||||
\texttt{return 0x1234; errno 0}, \\
|
||||
\texttt{return -1; errno ENOMEM}.
|
||||
|
||||
Some libc functions return their results via a pointer which was previously given to them as an argument.
|
||||
The \texttt{pipe} function is called with an \texttt{int} array of size two as argument and stores its two pipe ends into this array.
|
||||
Some libc functions return their results via a pointer, which was previously given to them as an argument.
|
||||
The \texttt{pipe} function is called with an \texttt{int} array of size two as an argument and stores its two pipe ends into this array.
|
||||
The \texttt{read} function is called with a pointer to a buffer and a corresponding size and stores its read data into this buffer.
|
||||
|
||||
Example (\texttt{pipe}): \\
|
||||
@@ -548,7 +547,7 @@ This includes the offset relative to the calling binary and a source file and li
|
||||
|
||||
\begin{listing}[htbp]
|
||||
\inputminted[fontsize=\tiny]{text}{src/listings/intercept-client.txt}
|
||||
\caption{Recoreded function calls from \texttt{./client}.}
|
||||
\caption{Recorded function calls from \texttt{./client}.}
|
||||
\label{lst:intercept-client}
|
||||
\end{listing}
|
||||
|
||||
@@ -565,7 +564,7 @@ The \texttt{free} function, on the other hand, has the pre-condition that the pa
|
||||
Any violation of such pre- and post-conditions may be reported as non-compliant behavior.
|
||||
\cite{malloc.3}
|
||||
|
||||
This means that intercepted function calls allow a tester to check if programmers use library function in compliance to their specification.
|
||||
This means that intercepted function calls allow a tester to check whether programmers use library functions in compliance with their specifications.
|
||||
Other checks may also include guards to calls to ``forbidden'' functions, or that specific functions must be called exactly three times.
|
||||
Another important post-condition of most library functions is the return value, which in most cases indicates success or failure of an operation.
|
||||
However, intercepting of calls alone may not be able to verify if a program really checks the return value of a function and acts accordingly.
|
||||
@@ -597,7 +596,7 @@ By only intercepting these functions, it is possible to check if all allocated m
|
||||
|
||||
\subsection{Validating Resource Management}\label{subsec:validating-resource-management}
|
||||
|
||||
Besides memory management, the proper use of other resources, most notably file descriptors, may be checked.
|
||||
In addition to memory management, the proper use of other resources---most notably file descriptors---can also be checked.
|
||||
Many functions in the C standard library rely on file descriptors.
|
||||
It may be checked if file descriptors were properly acquired, if only previously acquired file descriptors are used, and if these file descriptors are closed after their use.
|
||||
Relevant for this work are also semaphores because they do not rely on file descriptor in their API\@.
|
||||
|
||||
Reference in New Issue
Block a user