151 |
|
|
152 |
/* The server side. */ |
/* The server side. */ |
153 |
|
|
154 |
|
/* Containers are created in both the sender and receiver user list, |
155 |
|
so that at look up time (when the messages come in), only one of |
156 |
|
the both lists (the right one) is locked and verified. Otherwise |
157 |
|
there could be DoS attacks where a malicious receiver constantly |
158 |
|
claims it wants to accept a container from another client and keeps |
159 |
|
the user list of that client locked during the verification |
160 |
|
attempts. |
161 |
|
|
162 |
|
First the sender container is created. |
163 |
|
|
164 |
|
Then the receiver container is created. |
165 |
|
|
166 |
|
Removal of containers works the other way round. This is the most |
167 |
|
robust way to do it, in case the sender destroys the container |
168 |
|
asynchronously with the receiver trying to accept the container. |
169 |
|
First an invalid send container (id) has to be allocated, then the |
170 |
|
receiver container has to be created, and then the sender container |
171 |
|
can be filled with the right receiver container id. */ |
172 |
|
|
173 |
/* Create a reference container for DEST. */ |
/* Create a reference container for DEST. */ |
174 |
error_t |
error_t |
175 |
hurd_cap_server_create_ref_cont_S (l4_thread_id_t sender_thread, |
hurd_cap_server_create_ref_cont_S (l4_thread_id_t sender_thread, |
233 |
4. Enter the capability into the SENDER user list. Return its |
4. Enter the capability into the SENDER user list. Return its |
234 |
ID. */ |
ID. */ |
235 |
} |
} |
236 |
|
|
237 |
|
|
238 |
|
error_t |
239 |
|
hurd_cap_server_destroy_ref_cont (hurd_cap_t cap, hurd_cap_scid_t cont_id) |
240 |
|
{ |
241 |
|
/* 1. Look up the container in the sender user list. Verify the |
242 |
|
request. Then unlock the sender user list. |
243 |
|
|
244 |
|
The order matters! in the following two steps (the reason is that |
245 |
|
otherwise a sender container id could be reused while |
246 |
|
concurrently a receiver tries to accept the handle, and get the |
247 |
|
wrong one. This is a robustness issue for the case of a canceled |
248 |
|
RPC, for example): |
249 |
|
|
250 |
|
2. Remove the container from the receiver user list. |
251 |
|
|
252 |
|
3. Remove the container from the sender user list. */ |
253 |
|
} |