]>
Commit | Line | Data |
---|---|---|
e6390aca RS |
1 | =pod |
2 | ||
3 | =head1 NAME | |
4 | ||
5 | CRYPTO_free_ex_index, CRYPTO_get_ex_new_index, CRYPTO_set_ex_data, | |
6 | CRYPTO_get_ex_data, CRYPTO_free_ex_data | |
7 | - functions supporting application-specific data | |
8 | ||
9 | =head1 SYNOPSIS | |
10 | ||
11 | #include <openssl/crypto.h> | |
12 | ||
13 | int CRYPTO_get_ex_new_index(int class_index, | |
14 | long argl, void *argp, | |
15 | CRYPTO_EX_new *new_func, | |
16 | CRYPTO_EX_dup *dup_func, | |
17 | CRYPTO_EX_free *free_func); | |
18 | ||
19 | typedef int CRYPTO_EX_new(void *parent, void *ptr, CRYPTO_EX_DATA *ad, | |
20 | int idx, long argl, void *argp); | |
21 | typedef void CRYPTO_EX_free(void *parent, void *ptr, CRYPTO_EX_DATA *ad, | |
22 | int idx, long argl, void *argp); | |
23 | typedef int CRYPTO_EX_dup(CRYPTO_EX_DATA *to, CRYPTO_EX_DATA *from, | |
24 | void *from_d, int idx, long argl, void *argp); | |
25 | ||
26 | int CRYPTO_set_ex_data(CRYPTO_EX_DATA *r, int idx, void *arg); | |
27 | ||
28 | void *CRYPTO_get_ex_data(CRYPTO_EX_DATA *r, int idx); | |
29 | ||
30 | void CRYPTO_free_ex_data(int class_index, void *obj, CRYPTO_EX_DATA *r); | |
31 | ||
32 | int CRYPTO_free_ex_index(int class_index, int idx); | |
33 | ||
34 | =head1 DESCRIPTION | |
35 | ||
36 | Several OpenSSL structures can have application-specific data attached to them, | |
37 | known as "exdata." | |
38 | The specific structures are: | |
39 | ||
40 | SSL | |
41 | SSL_CTX | |
42 | SSL_SESSION | |
43 | X509 | |
44 | X509_STORE | |
45 | X509_STORE_CTX | |
46 | DH | |
47 | DSA | |
3aef36ff | 48 | EC_KEY |
e6390aca RS |
49 | RSA |
50 | ENGINE | |
51 | UI | |
52 | BIO | |
53 | ||
54 | Each is identified by an B<CRYPTO_EX_INDEX_xxx> define in the B<crypto.h> | |
55 | header file. In addition, B<CRYPTO_EX_INDEX_APP> is reserved for | |
56 | applications to use this facility for their own structures. | |
57 | ||
58 | The API described here is used by OpenSSL to manipulate exdata for specific | |
59 | structures. Since the application data can be anything at all it is passed | |
60 | and retrieved as a B<void *> type. | |
61 | ||
62 | Exdata types are identified by an B<index>, an integer guaranteed to be | |
63 | unique within structures for the lifetime of the program. Applications | |
64 | using exdata typically call B<CRYPTO_get_ex_new_index> at startup, and | |
65 | store the result in a global variable, or write a wrapper function to | |
66 | provide lazy evaluation. The B<class_index> should be one of the | |
67 | B<CRYPTO_EX_INDEX_xxx> values. The B<argl> and B<argp> parameters are saved | |
68 | to be passed to the callbacks but are otherwise not used. In order to | |
69 | transparently manipulate exdata, three callbacks must be provided. The | |
70 | semantics of those callbacks are described below. | |
71 | ||
72 | When copying or releasing objects with exdata, the callback functions | |
73 | are called in increasing order of their B<index> value. | |
74 | ||
75 | If a dynamic library can be unloaded, it should call CRYPTO_free_ex_index() | |
76 | when this is done. | |
77 | This will replace the callbacks with no-ops | |
78 | so that applications don't crash. Any existing exdata will be leaked. | |
79 | ||
80 | To set or get the exdata on an object, the appropriate type-specific | |
81 | routine must be used. This is because the containing structure is opaque | |
82 | and the B<CRYPTO_EX_DATA> field is not accessible. In both API's, the | |
83 | B<idx> parameter should be an already-created index value. | |
84 | ||
85 | When setting exdata, the pointer specified with a particular index is saved, | |
86 | and returned on a subsequent "get" call. If the application is going to | |
87 | release the data, it must make sure to set a B<NULL> value at the index, | |
d3054fb6 | 88 | to avoid likely double-free crashes. |
e6390aca RS |
89 | |
90 | The function B<CRYPTO_free_ex_data> is used to free all exdata attached | |
91 | to a structure. The appropriate type-specific routine must be used. | |
92 | The B<class_index> identifies the structure type, the B<obj> is | |
93 | be the pointer to the actual structure, and B<r> is a pointer to the | |
94 | structure's exdata field. | |
95 | ||
96 | =head2 Callback Functions | |
97 | ||
98 | This section describes how the callback functions are used. Applications | |
99 | that are defining their own exdata using B<CYPRTO_EX_INDEX_APP> must | |
100 | call them as described here. | |
101 | ||
102 | When a structure is initially allocated (such as RSA_new()) then the | |
103 | new_func() is called for every defined index. There is no requirement | |
104 | that the entire parent, or containing, structure has been set up. | |
105 | The new_func() is typically used only to allocate memory to store the | |
106 | exdata, and perhaps an "initialized" flag within that memory. | |
107 | The exdata value should be set by calling CRYPTO_set_ex_data(). | |
108 | ||
109 | When a structure is free'd (such as SSL_CTX_free()) then the | |
110 | free_func() is called for every defined index. Again, the state of the | |
111 | parent structure is not guaranteed. The free_func() may be called with a | |
112 | NULL pointer. | |
113 | ||
114 | Both new_func() and free_func() take the same parameters. | |
115 | The B<parent> is the pointer to the structure that contains the exdata. | |
116 | The B<ptr> is the current exdata item; for new_func() this will typically | |
117 | be NULL. The B<r> parameter is a pointer to the exdata field of the object. | |
118 | The B<idx> is the index and is the value returned when the callbacks were | |
119 | initially registered via CRYPTO_get_ex_new_index() and can be used if | |
120 | the same callback handles different types of exdata. | |
121 | ||
122 | dup_func() is called when a structure is being copied. This is only done | |
123 | for B<SSL> and B<SSL_SESSION> objects. The B<to> and B<from> parameters | |
124 | are pointers to the destination and source B<CRYPTO_EX_DATA> structures, | |
125 | respectively. The B<srcp> parameter is a pointer to the source exdata. | |
126 | When the dup_func() returns, the value in B<srcp> is copied to the | |
d3054fb6 BK |
127 | destination ex_data. If the pointer contained in B<srcp> is not modified |
128 | by the dup_func(), then both B<to> and B<from> will point to the same data. | |
129 | The B<idx>, B<argl> and B<argp> parameters are as described for the other | |
130 | two callbacks. | |
e6390aca RS |
131 | |
132 | =head1 RETURN VALUES | |
133 | ||
134 | CRYPTO_get_ex_new_index() returns a new index or -1 on failure; the | |
135 | value B<0> is reserved for the legacy "app_data" API's. | |
136 | ||
137 | CRYPTO_free_ex_index() and | |
138 | CRYPTO_set_ex_data() return 1 on success or 0 on failure. | |
139 | ||
140 | CRYPTO_get_ex_data() returns the application data or NULL on failure; | |
141 | note that NULL may be a valid value. | |
142 | ||
143 | dup_func() should return 0 for failure and 1 for success. | |
144 | ||
145 | =cut |