resea

resea copied to clipboard

Currently, the handle management library (libs/resea/handle.c) use the pair of a client task ID and task-local ID (handle_t) as a handle, e.g., file handle in fs servers and TCP sockets in tcpip server. The problem is that, since it checks the client task ID to deny accessing other tasks' handles, user programs can't transfer their own handles to others.

This is the tracking issue for supporting handle type in IPC to allow handle transferring like SCM_RIGHTS in Linux.

Idea: use a sufficiently-long random ID

• A server allocates a sufficiently-long ID (say 2^128 bits) as a handle.
  • Brute force attack on a large space is inevitable: even if each attempt can finish in 1 nanosecond, trying 2^128 take far longer than the age of the universe.
• Clients simply use or share the allocated ID to use the resource.

Pros

• We don't need to implement anything in kernel.

Cons

• We can't move the handle ownership: every tasks that know the handle ID can use the handle.

Idea: encrypted handle

• IIRC, this idea is inspired by a IPC mechanism in a L4 microkernel implementation.
• A server encrypts a 32/64-bits long value (like a user pointer to the server's control block for the handle) using server's private key.
• Encrypted value is used as the handle. Clients can use or share the handle by simply copying it.

Pros

• Like JWT, the handle is self-contained: the server don't have to manage a table to manage handles.

Cons

• We can't move the handle ownership: every tasks that know the handle ID can use the handle.