To Jonathan [readonly?]

[Anton Tagunov]

Hi,

Jonathan wrote:

> referring to the "Reloaded" networking design
> and perhaps to the EWS window system design.

> Both designs share a common pattern:
> there is some service that builds a
> memory region using client-supplied
> storage.

> 1.Does the *data* in these spaces need to be opaque to the clients?

>   Obviously not, since in both cases the service immediately gives the
>   client read access to the data ...

>   the space MUST be read-only to the client
>   (client can still revoke, but not write) ...

>   this satisfies Marcus's desire to inspect, but not to insert
>   (e.g.) breakpoints.

> 2.Does the *metadata* (that is: the mapping tables) need to be opaque
>   to the client? ... readability would not be a problem

Looks like some convergence in opinions? ;-)

>   However, it is possible to imagine other servers where the server
>   would store *capabilities* into a client-supplied capability address
>   space. If so, it may be that the client should not be permitted to
>   fetch *those* capabilities at all, and in that case even read access
>   is too much.

Can we design capabilities in such a way that reading a memory
region holding them would give no benefit to the reader?

Can they somehow be "tied" to the process holding them?

For instance the process would have an int key known only to kernel
and the capability would include a XOR of main part of it with this key?


regards,
Anton

P.S. Sorry for spawning 2 threads of discussion.
I think both of my "To Jonathan" threads
are promising avenues for thinking.