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