Process Key question

[Jonathan Adams]

I'm not sure if this case is compelling, but here goes:

The case is:

1) A service process must CALL a key passed in from its caller.  In the 
current EROS design, if the key is a key to the process itself, it will 
block forever.  It therefore needs some way of detecting whether or not 
the key is a start key to itself.  

One resolution is "The processes which need this ability are rare enough 
that the additional security analysis which is required is not worth it," 
in which case you give Discrim to any process that needs this.

Another is "The owner of the process should be smart enough not to pass 
in a key to itself."  This would imply that the object can never be 
passed to any untrusted code, since a trivial denial of service attack is 
to SEND the service itself.

A third would be "The kernel should detect a process CALLing itself."  
The question would then be "How does the kernel indicate to the process 
that this has happened,"  since anything it can return could also have been 
returned by the invoked key.  This is not as much of a problem for this 
case, since we can verify that the key is a key to someone running the 
service code (which we trust), but could have implications for other 
processes.

And a last one would be "This is compelling, and we should think about 
the security implications"

I'm really not sure what the answer here is.


As an example of this case, here is KeySet's version of it:

A KeySet can be asked by its caller to, say, check if it is a subset of 
another set.  In order to do this, it needs:

1) To check that the passed in key is, in fact, a key to a valid keyset
2) Get part of the data segment of the other keyset, which must be in a 
known state
3) guarentee that the other keyset does not touch the segment while the 
first keyset is reading the data.
4) Once it is done with the segment, notify the other segment that it can 
resume processing.

The way this is currently done is:

1)  The keyset uses it's Process Creator to open the passed key.  If this 
succeeds, we know the key is a key to a keyset.  It also gets a Process 
key to the refered to KeySet.

2)  The keyset verifies that the key is not a key to itself.  To do this, 
the keyset uses discrim to compare the Process key returned by the 
Process creator to it's own process key.  If they are the same, it 
immediatly returns "Yes, I'm a subset of myself"

3)  Now it creates a start key with a special KeyData field to the other 
KeySet, using the Process key returned from the Process Creator.  It 
CALLs this key with a special order code, starting a coroutine invocation.

4) The other process, seeing the special order code, verifies the KeyData 
field.  It then puts its data segment in a known state (i.e. sorted), and 
CALLs the resume key, passing a read-only key to its data segment.  Since 
it used CALL, it is guarenteed not to be doing any service processing 
until the first process invokes the Resume key.

The rest of the details are unimportant.

Hope this helps,
- Jonathan Adams