Browse code

Added memory management documentation

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>

David Sommerseth authored on 2011/07/29 06:25:07
Showing 2 changed files
... ...
@@ -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
+ */