Process Key question
Sun, 5 Apr 1998 17:46:54 -0700 (PDT)
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
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
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
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