The problem with the Signal service implementation.

[Norman Feske]

Hello Ivan,

> addr_t genode_ep = env()->ram_session_cap().dst();
> for(long badge = 0;; badge++)
> {
>      Dummy_client client(Native_capability(genode_ep, badge));
>      client.call_dummy_rpc_1();
>      ...
>      client.call_dummy_rpc_k(); // say k>10
> }
> 
> May be we don't understand Genode and Fiasco.OC completely and you can 
> explain this behaviour.

your observation is correct. Even though we use kernel capabilities for
constraining access to individual entrypoints, there is currently no
check in place to test the integrity of the supplied unique IDs at the
server side. Once you gain access to an entrypoint (in your example to
the entrypoint that provides the RAM service) you can invoke any object
managed by this particular entrypoint by guessing the object's unique
ID. This is particularly bad for core's entrypoints.

For Fiasco.OC, we could implement a check in the lines of the idea I
outlined in my previous email. As we use the same value as badge as for
the unique ID, a comparison (incoming badge == unique ID?) would prevent
the attack.

So you are completely right about the current implementation being
incomplete. The good message is that it can be fixed without changing
the API.

Cheers
Norman