151 |
|
|
152 |
/* The server side. */ |
/* The server side. */ |
153 |
|
|
154 |
/* Containers are created in both the sender and receiver user list, |
/* Containers are created in the sender's user list, but hold a |
155 |
so that at look up time (when the messages come in), only one of |
reference for the receiver user list. The receiver user list also |
156 |
the both lists (the right one) is locked and verified. Otherwise |
has a section with backreferences to all containers for this |
157 |
there could be DoS attacks where a malicious receiver constantly |
receiver. |
158 |
claims it wants to accept a container from another client and keeps |
|
159 |
the user list of that client locked during the verification |
At look up time, the receiver user list can be looked up. Then the |
160 |
attempts. |
small list can be searched to verify the request. If it is |
161 |
|
verified, the entry can be removed. Then the sender can be looked |
162 |
|
up to access the real reference container item. The reference for |
163 |
|
the receiver user list should not be released because it will |
164 |
|
usually be consumed for the capability. |
165 |
|
|
166 |
|
Without the small list on the receiver user list side there could |
167 |
|
be DoS attacks where a malicious receiver constantly claims it |
168 |
|
wants to accept a container from another client and keeps the user |
169 |
|
list of that client locked during the verification attempts. |
170 |
|
|
171 |
First the sender container is created. |
First the sender container is created. |
172 |
|
|
193 |
1. Check if a user list for dest exists, if not, create one. Use |
1. Check if a user list for dest exists, if not, create one. Use |
194 |
the senders task ID as a constraint to the task_info_create call, to |
the senders task ID as a constraint to the task_info_create call, to |
195 |
ensure we don't create a task info cap if the sender dies in the |
ensure we don't create a task info cap if the sender dies in the |
196 |
meantime. Implemention note: Split the container ID in two fields, |
meantime. |
|
each 16 bit, one for the sender cont id and one for the receiver |
|
|
cont id. |
|
197 |
|
|
198 |
Note: Order matters in the following two steps: |
Note: Order matters in the following two steps: |
199 |
|
|
200 |
2. Register the container as a sending container with the sender user list. |
2. Register the container as a sending container with the sender user list. |
201 |
|
|
202 |
3. Register the container as a receiving container with the dest user list. |
3. Register the container as a receiving container with the dest |
203 |
|
user list. The user dest list should have its own small list just |
204 |
|
with containers, and this list should have its own lock. There is |
205 |
|
no precondition for this lock. A non-empty list implies one |
206 |
|
reference to the task info cap (no explicit reference is taken to |
207 |
|
avoid locking problems). |
208 |
|
|
209 |
This is how task death notifications should be handled: |
This is how task death notifications should be handled: |
210 |
|
|
250 |
error_t |
error_t |
251 |
hurd_cap_server_destroy_ref_cont (hurd_cap_t cap, hurd_cap_scid_t cont_id) |
hurd_cap_server_destroy_ref_cont (hurd_cap_t cap, hurd_cap_scid_t cont_id) |
252 |
{ |
{ |
253 |
/* 1. Look up the container in the sender user list. Verify the |
/* To be written */ |
|
request. Then unlock the sender user list. |
|
|
|
|
|
The order matters! in the following two steps (the reason is that |
|
|
otherwise a sender container id could be reused while |
|
|
concurrently a receiver tries to accept the handle, and get the |
|
|
wrong one. This is a robustness issue for the case of a canceled |
|
|
RPC, for example): |
|
|
|
|
|
2. Remove the container from the receiver user list. |
|
|
|
|
|
3. Remove the container from the sender user list. */ |
|
254 |
} |
} |