[okl4-developer] OKL4 v2.1: about thread identifiers

[Frank Kaiser]

Hi, Geoffrey & Josh

Thanks for your responses.
However, what I've learned about the reply cap feature so far is insufficient for my purpose. The main constraint is that it can only be used once as an immediate response to an IPC. For a virtual server this is of little use, since practically the server is not able to provide an immediate response in many cases.
Let me describe a use case. Typically an SPI interface supports 4 devices, each of which can serve a different purpose. The SPI's server interface would allow up to 4 clients each of which would communicate with one device. When setting up the system properties it would be declared that these for clients are allowed to communicate with the server.
When the system starts each of the clients would register to the server describing the details of the communication including selecting the device. The reception by the server indicates that the IPC has passed the security control. But this does only tell that it is one of the 4 clients, but not which one. As soon as the second client comes into play, the server requires to identify a client to assure that a subsequent communication request of the client is routed to the correct device.
SPI communication works duplex in such a way that the SPI interface is in parallel receiving as many bytes as it sends. After having received the data from the device the server has to transfer the data to that client which provided the sent data. For this transfer the reply cap related to the client's communication request cannot be used, since the context has been lost. So the server again requires a means to identify the client.
For a safe system the client identification must not be dependent on something given by the client itself, because this can be erroneous or faked. Therefore client identification must be provided by the system. The most simple solution obviously is, that the client would be able to determine the sender's threadid from any IPC it receives, which the server then can use for any type of response.
For my given example this would allow:
- Derive the client threadid from the registration IPC and store it as an identification together with other parameters like the selected SPI device for subsequent communication request.
- Compare the client threadid of a communication request with the one stored from the registration request to select the correct device and apply other plausibility checks, and use the threadid to return the received data to the client.
I do not see how the reply cap feature is able to support this concept. For safe operating the server must be able to obtain the client's threadid from the system. Is there a way to obtain the threadid behind a reply cap or any other L4 function to obtain the threadid of an IPC sender?

Regards
Frank
> -----Original Message-----
> From: Geoffrey Lee [mailto:glee at ok-labs.com]
> Sent: Thursday, September 18, 2008 9:40 AM
> To: Frank Kaiser
> Cc: Joshua Root; developer at okl4.org
> Subject: Re: [okl4-developer] OKL4 v2.1: about thread identifiers
> 
> On Tue, Sep 16, 2008 at 06:05:42PM +0200, Frank Kaiser wrote:
> > Hello, Josh
> >
> 
> > The client using my SPI server should register to the server. When the
> client initiates a data exchange, then the server shall check that it is
> coming from the registered client. Furthermore the server shall return a
> notification after the data exchange is completed, so that the client need not
> to block on the data exchange call. For both purposes the server needs the
> true thread id of the caller. Since the IPC syscall does not provide it
> anymore, and the reply cap is a one-shot feature, I had to add an additional
> parameter carrying the thread id to my IDL4 interface specification. However,
> this approach has the shortcoming, that the client id is not maintained by the
> system, allowing any other client interfering with the connection by using a
> wrong thread id (the one, belonging the the true client). This not only
> creates an unwanted error possibility, but also a security hole, since the
> server cannot reliably recognize that it receives commands from the right
> client.
> > This way I cannot see that the reply cap feature in its current stage is an
> enhancement with respect to system security.
> 
> 
> Hi Frank -  Just to add to Josh's reply, as you have noted trusting the client
> to send you a correct piece of identification information is a bad
> idea, however it should not be taken to imply that reply caps
> does not help with system security or even worse compromise it.
> Reply caps means that you cannot communicate with other threads
> in the system in an arbitary fashion, which stops leakage of
> information unless the thread has been specifically granted permission
> to do so.
> >
> > Regards
> > Frank
> 
> 	-gl