Signed-off-by: Adriaan de Jong <dejong@fox-it.com>
Acked-by: James Yonan <james@openvpn.net>
Signed-off-by: David Sommerseth <dazo@users.sourceforge.net>
... | ... |
@@ -42,14 +42,30 @@ |
42 | 42 |
#define BUF_INIT_TRACKING |
43 | 43 |
#endif |
44 | 44 |
|
45 |
-/* basic buffer class for OpenVPN */ |
|
46 |
- |
|
45 |
+/**************************************************************************/ |
|
46 |
+/** |
|
47 |
+ * Wrapper structure for dynamically allocated memory. |
|
48 |
+ * |
|
49 |
+ * The actual content stored in a \c buffer structure starts at the memory |
|
50 |
+ * location \c buffer.data \c + \c buffer.offset, and has a length of \c |
|
51 |
+ * buffer.len bytes. This, together with the space available before and |
|
52 |
+ * after the content, is represented in the pseudocode below: |
|
53 |
+@code |
|
54 |
+uint8_t *content_start = buffer.data + buffer.offset; |
|
55 |
+uint8_t *content_end = buffer.data + buffer.offset + buffer.len; |
|
56 |
+int prepend_capacity = buffer.offset; |
|
57 |
+int append_capacity = buffer.capacity - (buffer.offset + buffer.len); |
|
58 |
+@endcode |
|
59 |
+ */ |
|
47 | 60 |
struct buffer |
48 | 61 |
{ |
49 |
- int capacity; /* size of buffer allocated by malloc */ |
|
50 |
- int offset; /* data starts at data + offset, offset > 0 to allow for efficient prepending */ |
|
51 |
- int len; /* length of data that starts at data + offset */ |
|
52 |
- uint8_t *data; |
|
62 |
+ int capacity; /**< Size in bytes of memory allocated by |
|
63 |
+ * \c malloc(). */ |
|
64 |
+ int offset; /**< Offset in bytes of the actual content |
|
65 |
+ * within the allocated memory. */ |
|
66 |
+ int len; /**< Length in bytes of the actual content |
|
67 |
+ * within the allocated memory. */ |
|
68 |
+ uint8_t *data; /**< Pointer to the allocated memory. */ |
|
53 | 69 |
|
54 | 70 |
#ifdef BUF_INIT_TRACKING |
55 | 71 |
const char *debug_file; |
... | ... |
@@ -57,18 +73,41 @@ struct buffer |
57 | 57 |
#endif |
58 | 58 |
}; |
59 | 59 |
|
60 |
-/* for garbage collection */ |
|
61 | 60 |
|
61 |
+/**************************************************************************/ |
|
62 |
+/** |
|
63 |
+ * Garbage collection entry for one dynamically allocated block of memory. |
|
64 |
+ * |
|
65 |
+ * This structure represents one link in the linked list contained in a \c |
|
66 |
+ * gc_arena structure. Each time the \c gc_malloc() function is called, |
|
67 |
+ * it allocates \c sizeof(gc_entry) + the requested number of bytes. The |
|
68 |
+ * \c gc_entry is then stored as a header in front of the memory address |
|
69 |
+ * returned to the caller. |
|
70 |
+ */ |
|
62 | 71 |
struct gc_entry |
63 | 72 |
{ |
64 |
- struct gc_entry *next; |
|
73 |
+ struct gc_entry *next; /**< Pointer to the next item in the |
|
74 |
+ * linked list. */ |
|
65 | 75 |
}; |
66 | 76 |
|
77 |
+ |
|
78 |
+/** |
|
79 |
+ * Garbage collection arena used to keep track of dynamically allocated |
|
80 |
+ * memory. |
|
81 |
+ * |
|
82 |
+ * This structure contains a linked list of \c gc_entry structures. When |
|
83 |
+ * a block of memory is allocated using the \c gc_malloc() function, the |
|
84 |
+ * allocation is registered in the function's \c gc_arena argument. All |
|
85 |
+ * the dynamically allocated memory registered in a \c gc_arena can be |
|
86 |
+ * freed using the \c gc_free() function. |
|
87 |
+ */ |
|
67 | 88 |
struct gc_arena |
68 | 89 |
{ |
69 |
- struct gc_entry *list; |
|
90 |
+ struct gc_entry *list; /**< First element of the linked list of |
|
91 |
+ * \c gc_entry structures. */ |
|
70 | 92 |
}; |
71 | 93 |
|
94 |
+ |
|
72 | 95 |
#define BPTR(buf) (buf_bptr(buf)) |
73 | 96 |
#define BEND(buf) (buf_bend(buf)) |
74 | 97 |
#define BLAST(buf) (buf_blast(buf)) |
75 | 98 |
new file mode 100644 |
... | ... |
@@ -0,0 +1,99 @@ |
0 |
+/* |
|
1 |
+ * OpenVPN -- An application to securely tunnel IP networks |
|
2 |
+ * over a single TCP/UDP port, with support for SSL/TLS-based |
|
3 |
+ * session authentication and key exchange, |
|
4 |
+ * packet encryption, packet authentication, and |
|
5 |
+ * packet compression. |
|
6 |
+ * |
|
7 |
+ * Copyright (C) 2010 Fox Crypto B.V. <openvpn@fox-it.com> |
|
8 |
+ * |
|
9 |
+ * |
|
10 |
+ * This program is free software; you can redistribute it and/or modify |
|
11 |
+ * it under the terms of the GNU General Public License version 2 |
|
12 |
+ * as published by the Free Software Foundation. |
|
13 |
+ * |
|
14 |
+ * This program is distributed in the hope that it will be useful, |
|
15 |
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of |
|
16 |
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
|
17 |
+ * GNU General Public License for more details. |
|
18 |
+ * |
|
19 |
+ * You should have received a copy of the GNU General Public License |
|
20 |
+ * along with this program (see the file COPYING included with this |
|
21 |
+ * distribution); if not, write to the Free Software Foundation, Inc., |
|
22 |
+ * 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA |
|
23 |
+ */ |
|
24 |
+ |
|
25 |
+/** |
|
26 |
+ * @file |
|
27 |
+ * Memory management strategies documentation file. |
|
28 |
+ */ |
|
29 |
+ |
|
30 |
+/** |
|
31 |
+ * @page memory_management OpenVPN's memory management strategies |
|
32 |
+ * |
|
33 |
+ * This section describes several implementation details relating to |
|
34 |
+ * OpenVPN's memory management strategies. |
|
35 |
+ * |
|
36 |
+ * During operation, the OpenVPN process performs all kinds of operations |
|
37 |
+ * on blocks of data. Receiving packets, encrypting content, prepending |
|
38 |
+ * headers, etc. To make the programmer's job easier and to decrease the |
|
39 |
+ * likelihood of memory-related bugs, OpenVPN uses its own memory %buffer |
|
40 |
+ * library and garbage collection facilities. These are described in |
|
41 |
+ * brief here. |
|
42 |
+ * |
|
43 |
+ * @section memory_management_buffer The buffer structure |
|
44 |
+ * |
|
45 |
+ * The \c buffer structure is a wrapper around a block of dynamically |
|
46 |
+ * allocated memory which keeps track of the block's capacity \c |
|
47 |
+ * buffer.capacity and location in memory \c buffer.data. This structure |
|
48 |
+ * supports efficient prepending and appending within the allocated memory |
|
49 |
+ * through the use of offset \c buffer.offset and length \c buffer.len |
|
50 |
+ * fields. See the \c buffer documentation for more details on the |
|
51 |
+ * structure itself. |
|
52 |
+ * |
|
53 |
+ * OpenVPN's %buffer library, implemented in the \c buffer.h and \c |
|
54 |
+ * buffer.c files, contains many utility functions for working with \c |
|
55 |
+ * buffer structures. These functions facilitate common operations, such |
|
56 |
+ * as allocating, freeing, reading and writing to \c buffer structures, |
|
57 |
+ * and even offer several more advanced operations, such as string |
|
58 |
+ * matching and creating sub-buffers. |
|
59 |
+ * |
|
60 |
+ * Not only do these utility functions make working with \c buffer |
|
61 |
+ * structures easy, they also perform extensive error checking. Each |
|
62 |
+ * function, where necessary, checks whether enough space is available |
|
63 |
+ * before performing its actions. This minimizes the chance of bugs |
|
64 |
+ * leading to %buffer overflows and other vulnerabilities. |
|
65 |
+ * |
|
66 |
+ * @section memory_management_frame The frame structure |
|
67 |
+ * |
|
68 |
+ * The \c frame structure keeps track of the maximum allowed packet |
|
69 |
+ * geometries of a network connection. |
|
70 |
+ * |
|
71 |
+ * It is used, for example, to determine the size of \c buffer structures |
|
72 |
+ * in which to store data channel packets. This is done by having each |
|
73 |
+ * data channel processing module register the maximum amount of extra |
|
74 |
+ * space it will need for header prepending and content expansion in the |
|
75 |
+ * \c frame structure. Once these parameters are known, \c buffer |
|
76 |
+ * structures can be allocated, based on the \c frame parameters, so that |
|
77 |
+ * they are large enough to allow efficient prepending of headers and |
|
78 |
+ * processing of content. |
|
79 |
+ * |
|
80 |
+ * @section memory_management_garbage Garbage collection |
|
81 |
+ * |
|
82 |
+ * OpenVPN has many sizable functions which perform various actions |
|
83 |
+ * depending on their %context. This makes it difficult to know in advance |
|
84 |
+ * exactly how much memory must be allocated. The garbage collection |
|
85 |
+ * facilities are used to keep track of dynamic allocations, thereby |
|
86 |
+ * allowing easy collective freeing of the allocated memory. |
|
87 |
+ * |
|
88 |
+ * The garbage collection system is implemented by the \c gc_arena and \c |
|
89 |
+ * gc_entry structures. The arena represents a garbage collecting unit, |
|
90 |
+ * and contains a linked list of entries. Each entry represents one block |
|
91 |
+ * of dynamically allocated memory. |
|
92 |
+ * |
|
93 |
+ * The garbage collection system also contains various utility functions |
|
94 |
+ * for working with the garbage collection structures. These include |
|
95 |
+ * functions for initializing new arenas, allocating memory of a given |
|
96 |
+ * size and registering the allocation in an arena, and freeing all the |
|
97 |
+ * allocated memory associated with an arena. |
|
98 |
+ */ |