/[hurd]/hurd-l4/libhurd-cap/cap-move.c
ViewVC logotype

Diff of /hurd-l4/libhurd-cap/cap-move.c

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.2 by marcus, Thu Aug 28 00:27:06 2003 UTC revision 1.3 by marcus, Sat Aug 30 04:21:31 2003 UTC
# Line 151  cap_receive (l4_thread_id_t sender_threa Line 151  cap_receive (l4_thread_id_t sender_threa
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    
# Line 184  hurd_cap_server_create_ref_cont_S (l4_th Line 193  hurd_cap_server_create_ref_cont_S (l4_th
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    
# Line 238  hurd_cap_server_accept_ref_cont (l4_thre Line 250  hurd_cap_server_accept_ref_cont (l4_thre
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  }  }

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26