|
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
|
|
467
|
20 \clearpage
|
|
0
|
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
|
|
90
|
35 choosing a library to load and a function to call without verification.
|
|
0
|
36 Such unchecked input data can quite easily be used to intentionally crash the
|
|
90
|
37 program or to take over control of the program flow.\\
|
|
|
38 If not used with care, programs depending on the \product{dyncall},
|
|
|
39 \product{dyncallback} and \product{dynload} libraries, can be exploited as
|
|
|
40 arbitrary function call dispatchers through manipulation of their input data.
|
|
|
41 Successful exploits of badly formed programs like outlined above can be misused
|
|
|
42 as powerful tools for a wide variety of malicious attacks, \ldots
|
|
0
|
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
|
|
90
|
49 to build the library as build-time dependencies, like a compiler and assembler,
|
|
|
50 linker, etc..
|
|
0
|
51 The library uses some heap-memory to store the CallVM and uses by default the
|
|
|
52 platform's \capi{malloc()} and \capi{free()} calls. However, providing custom
|
|
90
|
53 \capi{dcAllocMem} and \capi{dcFreeMem} C-preprocessor definitions will override
|
|
|
54 the default behaviour.
|
|
0
|
55 See \shell{dyncall/dyncall\_alloc.h} for details.
|
|
|
56
|
|
|
57
|
|
|
58 \subsection{Multi-threading}
|
|
|
59
|
|
|
60 The \product{dyncall} library is thread-safe and reentrant, by means that it
|
|
|
61 works correctly during execution of multiple threads if, and only if there is
|
|
90
|
62 at most a single thread pushing arguments to one CallVM. Since there's no
|
|
|
63 limitation on the number of created CallVM objects, it is recommended to keep a
|
|
|
64 copy per thread if mutliple threads make use of \product{dyncall} in parallel.
|
|
|
65 Invoking the call should always be thread-safe, however, whether the called
|
|
|
66 function is thread-safe is up to the programmer to verify, of course.
|
|
0
|
67
|
|
|
68 \subsection{Supported types}
|
|
|
69
|
|
|
70 Currently, the \product{dyncall} library supports all of ANSI C's integer,
|
|
90
|
71 floating point and pointer types as function call arguments and return values.
|
|
|
72 Additionally, C++'s \capi{bool} and C99's \capi{\_Bool} types are supported.
|
|
|
73 Due to the still rare and often incomplete support of the \capi{long double}
|
|
|
74 type on various platforms, the latter is currently not officially supported.
|
|
0
|
75
|
|
|
76 \subsection{Roadmap}
|
|
|
77
|
|
|
78 The \product{dyncall} library should be extended by a wide variety of other
|
|
90
|
79 calling conventions and ported to other and more esoteric platforms. With its
|
|
|
80 low memory footprint it surely comes in handy on embedded systems.
|
|
0
|
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
|
