0
|
1 %//////////////////////////////////////////////////////////////////////////////
|
|
2 %
|
|
3 % Copyright (c) 2007,2009 Daniel Adler <dadler@uni-goettingen.de>,
|
|
4 % Tassilo Philipp <tphilipp@potion-studios.com>
|
|
5 %
|
|
6 % Permission to use, copy, modify, and distribute this software for any
|
|
7 % purpose with or without fee is hereby granted, provided that the above
|
|
8 % copyright notice and this permission notice appear in all copies.
|
|
9 %
|
|
10 % THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
|
|
11 % WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
|
|
12 % MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
|
|
13 % ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
|
|
14 % WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
|
|
15 % ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
|
|
16 % OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
|
|
17 %
|
|
18 %//////////////////////////////////////////////////////////////////////////////
|
|
19
|
|
20 \newpage
|
|
21
|
|
22 \section{Epilog}
|
|
23
|
|
24 \subsection{Stability and security considerations}
|
|
25
|
|
26 Since the \product{dyncall} library doesn't know anything about the called
|
|
27 function itself (except its address), no parameter-type validation is done.
|
|
28 This means that in order to avoid crashes, data corruption, etc., the user is
|
|
29 required to ascertain the number and types of parameters. It is strongly advised to
|
|
30 double check the parameter types of every function to be called, and not to
|
|
31 call unknown functions at all.\\
|
|
32
|
|
33 Consider a simple program that issues a call by directly passing some
|
|
34 unchecked command line arguments to the call itself, or even worse, by indirectly
|
|
35 choosing a library and a function to call without verification.
|
|
36 Such unchecked input data can quite easily be used to intentionally crash the
|
|
37 program or to hijack it by taking over control of the program flow.\\
|
|
38 To put it in a nutshell, if not used with care, programs depending on the
|
|
39 \product{dyncall}, \product{dyncallback} and \product{dynload} libraries,
|
|
40 can be exploited as arbitrary function call dispatchers through manipulating
|
|
41 of their input data. Successful exploits of programs like the example outlined above
|
|
42 can be sed as very powerful tools for a wide variety of malicious attacks, \ldots
|
|
43
|
|
44
|
|
45 \subsection{Embedding}
|
|
46
|
|
47 The \product{dyncall} library strives to have a minimal set of dependencies,
|
|
48 meaning no required runtime dependencies and usually only the necessary tools
|
|
49 to build the library as build-time dependencies.
|
|
50 The library uses some heap-memory to store the CallVM and uses by default the
|
|
51 platform's \capi{malloc()} and \capi{free()} calls. However, providing custom
|
|
52 \capi{dcAllocMem()} and \capi{dcFreeMem()} functions will override the default
|
|
53 behaviour.
|
|
54 See \shell{dyncall/dyncall\_alloc.h} for details.
|
|
55
|
|
56
|
|
57 \subsection{Multi-threading}
|
|
58
|
|
59 The \product{dyncall} library is thread-safe and reentrant, by means that it
|
|
60 works correctly during execution of multiple threads if, and only if there is
|
|
61 at most a single thread pushing arguments to one CallVM (invoking the call is
|
|
62 always thread-safe, though). Since there's no limitation on the number of
|
|
63 created CallVM objects, it is recommended to keep a copy for each thread if
|
|
64 mutliple thread make use of \product{dyncall} at once.
|
|
65
|
|
66
|
|
67 \subsection{Supported types}
|
|
68
|
|
69 Currently, the \product{dyncall} library supports all of ANSI C's integer,
|
|
70 floating point and pointer types as function call arguments as well as return
|
|
71 values. Additionally, C++'s \capi{bool} and C99's \capi{\_Bool} types are supported.
|
|
72 Due to the still rare and often incomplete support of the \capi{long double} type
|
|
73 on various platforms, the latter is currently not officially supported.
|
|
74
|
|
75
|
|
76 \subsection{Roadmap}
|
|
77
|
|
78 The \product{dyncall} library should be extended by a wide variety of other
|
|
79 calling conventions and ported to other and more esoteric platforms. With its low
|
|
80 memory footprint it surely might come in handy on embedded systems.
|
|
81 Furthermore, the authors plan to provide more scripting language bindings,
|
|
82 examples, and other projects based on \product{dyncall}.\\
|
|
83 Besides \product{dyncall} and \product{dyncallback}, the \product{dynload}
|
|
84 library needs to be extended with support for other shared library formats
|
|
85 (e.g. AmigaOS .library or GEM \cite{.ldg} files).
|
|
86
|
|
87
|
|
88 \subsection{Related libraries}
|
|
89
|
|
90 Besides the \product{dyncall} library, there are other free and open projects
|
|
91 with similar goals. The most noteworthy libraries are libffi \cite{libffi},
|
|
92 C/Invoke \cite{cinvoke} and libffcall \cite{libffcall}.
|
|
93
|