Enabled by CHERIoT-Platform/cheriot-rtos#614 and similar to what we recently did in the allocator and in the message queue, we can use the three currently-unused bits at the bottom of sealed socket handles to store permissions.
Having permissions on sockets would allow us to encode the right to close a socket, send, or receive data. (Or more, ideas welcome!)
We could for example use these to enable compartmentalized applications that separate receiving data and sending data. If you do that with the existing socket API (or with other compartmentalized systems), you need three compartments: one that holds the socket, one that processes incoming data, and one that processes outgoing data. With socket permissions, you can eliminate the compartment that holds the socket, and just have the compartment that processes incoming data (holding a receive-only socket), and one that send data (holding a send-only socket). It reduces the number of domain switches on the hot path.
Enabled by CHERIoT-Platform/cheriot-rtos#614 and similar to what we recently did in the allocator and in the message queue, we can use the three currently-unused bits at the bottom of sealed socket handles to store permissions.
Having permissions on sockets would allow us to encode the right to close a socket, send, or receive data. (Or more, ideas welcome!)
We could for example use these to enable compartmentalized applications that separate receiving data and sending data. If you do that with the existing socket API (or with other compartmentalized systems), you need three compartments: one that holds the socket, one that processes incoming data, and one that processes outgoing data. With socket permissions, you can eliminate the compartment that holds the socket, and just have the compartment that processes incoming data (holding a receive-only socket), and one that send data (holding a send-only socket). It reduces the number of domain switches on the hot path.