Process Tool considered useful

Jonathan Shapiro jsshapiro@earthlink.net
Mon, 22 Dec 1997 15:23:45 -0800


good points, all of them.

Shouldn't the same arguments apply to the ability of a node to fabricate a
segment key?

-----Original Message-----
From: LANDAU_CHARLES@Tandem.COM <LANDAU_CHARLES@Tandem.COM>
To: shap@eros.cis.upenn.edu <shap@eros.cis.upenn.edu>
Cc: eros-arch@eros.cis.upenn.edu <eros-arch@eros.cis.upenn.edu>
Date: Monday, December 22, 1997 3:15 PM
Subject: Process Tool considered useful


>As the inventor of the KeyKOS domain (process) key, I feel compelled to
>respond.
>
>The node (capage) is merely a storage receptacle for keys. While it is
>true that a domain (process) contains a node at its root, it is no more
>reasonable to expect a node to know how to construct a process, than to
>expect it to know how to construct a supernode, factory, or application.
>
>In a heterogeneous system, there could be different types of processes;
>a 386 process, an R4000 process, etc. You wouldn't expect a 386 kernel
>to know how to make a process key to a R4000 process. The proper way to
>control this complexity is to have different creators for different
>kinds of processes.
>
>The domain tool (process tool?) is closely held because it creates only
>the kind of process known to the local kernel. This is something you
>might want to hide from general users, to prevent them from knowing, or
>needing to know, on what type of host they are running.
>
>
>------------   ORIGINAL ATTACHMENT   --------
>SENT 04-28-97 FROM SMTPGATE (shap@eros.cis.upenn.edu)
>
>I am debating the merits of the current process tool.  Norm asserts
>that the process tool need not be closely held for security reasons.
>If this is so, the only reason I can see for distinguishing the
>process tool is that the canopener operation cannot be performed on a
>kept red segment.
>
>If this is correct, then I propose the following change to the
>architecture:
>
>   process tool => renamed to canopener
>   mkprocess becomes an operation on a capage (node) key
>   mkstart, mkresume become an operation on a capage key
>   logical distinction between capage and process key is that
>     process key prohibits operations on brand slot.
>
>I believe this actually reduces the kernel size.
>
>What brought this to my attention was trying to formally describe the
>semantics of the capage key.
>
>
>Reactions?
>
>