Channel, Messages and Policy implementation discussion

[blaxill]

Currently we do not implement policies on channels or messages. This issue is for open discussion of implementation.

Messages need labels, channels also need labels as the number of messages written to a channel may itself depend on secret data.

(tiziano88)
for reference, this is how Fuchsia deals with writing to objects in various contexts:

• https://fuchsia.dev/fuchsia-src/reference/syscalls/channel_write
• https://fuchsia.dev/fuchsia-src/reference/syscalls/fifo_write
• https://fuchsia.dev/fuchsia-src/reference/syscalls/vmo_write

I just realised that they all rely on the same underlying ZX_RIGHT_WRITE right, which is exactly what I was going to suggest we do
i.e. keep track of rights associated with each handle from the point of view of each node
this does introduce some extra complexity in case in which a node creates a channel and gets back a handle with R+W rights, but wants to split it into two separate handles to pass to other nodes
turns out Fuchsia also solved this via https://fuchsia.dev/fuchsia-src/reference/syscalls/handle_duplicate , it seems
in which new rights can be specified when duplicating handles

[tiziano88]

My suggestion (though I haven't fully thought it out) is to treat channels and messages as specialisations of the same abstract concept of containers; a container would be an object owned by the runtime, and can be referenced by a handle (capability) by a node or from other containers. A container would be serialised as bytes + handles, and would have an associated label, also tracked by the runtime. The runtime also keeps track of handles to containers and their movements (via read and write operations), and it may require to move the transitive closure of handles to all the reachable containers even if only a single handle is sent over a channel.

We may either go with a linear approach for handles (i.e. unique, and always moved when sent over a channel), or a reference counting approach, in which the runtime keeps track of how many outstanding handles still refer to a particular container, and deallocates the container when it is no longer reachable from any running node.

As a side note, this model would also allow implementing other kinds of containers (e.g. CRDTs, FIFO, LIFO, ring buffers) quite easily.

/cc @project-oak/core