[coyotos-dev] [Fwd: Removing PC/PCC, "Amplify" discussion]

[Jonathan Adams]

We're at the point in the Coyotos design where we need to start
specifying the core userland domain interfaces.  One of our desires is
to remove the Process Creator (PC) and its creator (the PCC) from the
set of objects inherited from the EROS design.

Charles Landau proposed this 7 (!) years ago on eros-os;  here's a link
to the root of the thread:

http://www.eros-os.org/pipermail/eros-arch/2000-May/002150.html

There was also a recent discussion of the EROS/KeyKOS "Amplify"
operations on cap-talk, which starts:

http://www.eros-os.org/pipermail/cap-talk/2006-December/006465.html


Looking at the Process Creator's interfaces:

http://www.eros-os.org/devel/ObRef/standard/ProcessCreator.html

the allocation and process destruction functions can readily be moved
into the SpaceBank (the only "new" one .  The rights amplification
operations are a bit more sticky, though.  As a reminder, they are:

   Amplify Gate Key
	Takes a gate key.  If it is a gate key to a process 
	created by the invoked Process Creator, returns a Process 
	key to the process, as well as information about the gate key
	(i.e. is it a start/resume key, and for Start keys, what is
	it's KeyInfo value)

	If the key is not a gate key, or the process it points to 
	was not created by the invoked Process Creator, fail. 

   Amplify Address Space with Gate Key Keeper
	Similar to Amplify Gate key, but the argument is a segment
	which must have a keeper which is a gate key to a process 
	created by the invoked Process Creator.  In addition to
	the information returned by Amplify Gate Key, you also get
	an unrestricted node key to the passed in segment.

There are two main uses for the "Amplify" operations:

1.  Identification

	In order to do a trusted handshake with another process, you 
	need to know two things:

		a.  That the key will invoke a process of the 
		    expected type, and

		b.  That the key is *not* a key to yourself (otherwise,
		    invoking it will deadlock)

	With the current operation, (a) comes from the success of the
	"Amplify" operation, and (b) comes from doing a Discrim
	"compare" operation, to check that the resultant process key 
	is different from your own process key.

	Note that part (a), at least, is a generally available 
	operation:  anyone with the Constructor key can use it to
	identify the yield of that constructor.

2.  Amplification

	The data and keys returned by the "Amplify" operation 
	constitute a large increase in authority.  You get
	private data (the KeyData field), along with a Process key,
	which grants complete authority over a Process.

In EROS (and, as far as I can tell, KeyKOS; I'll use the EROS
terminology), any process created by a Constructor gets a capability to
the Process Creator for the Constructor.  This is mainly so that the
process could destroy itself.  

This has an interesting side effect:  any process can gain full control
of any process created by the same constructor that it has an invocation
key for *without any interaction with the other process*.  Further,
since any debugger necessarily has a Process key to the debugged
process, and therefore access to all of its capabilities, any debugger
can gain full access to any similar process.

For most processes, the ability to amplify *other* process's capabilities
is excessive authority.  The principle of least authority says that they
should therefore not have that authority by default.

The only user of the "amplify other process" capabilities call in EROS
is the KeySet, in order to facilitate an internal protocol to speed set 
union operations.  The protocol used can be adapted to only need
"identify".


Proposed resolution for Coyotos

The PC/PCC no longer exist.  Process allocation and destruction are the
purview of the Space Bank.  Constructors hold the "Process Tool", and
control the brands of the processes they create.

There will be a version of the "Constructor" key which can "Amplify" any
Sender capability to a process created by the constructor.  These would
be closely held, and are mainly to enable debugging the constructor's
yield.

The "Amplify" operation moves to the Process key, and only works on
capabilities which will invoke *that Process*.  It reports Protected
Payload and Endpoint IDs, but does not return a Process key, since you
invoked the only key it could possibly return.

The Process key gains a new "Identify" operation, which takes a Sender
capability, and returns one of three values:
	
	Identify_Mine:  The Sender capability will invoke the process
			the "Identify" operation was requested on.

	Identify_SameBrand:  The Sender capability, if invoked, will
			call a process with the same brand as the
			process the "Identify" operation was requested
			on. 

	Identify_Other:	The Sender capability will invoke a process 
			whose brand does not match the process the
			"Identify" operation was requested on.


An unresolved point is multi-threading;  if you need to be able to
unwrap a Sender key to any process in your group, at the moment you 
would need to invoke "Amplify" on each thread's Process capability.
That's a topic for a later discussion.


What do y'all think?

Cheers,

- jonathan