[EROS-Arch] Re: (processtool restriction)
Jonathan S. Shapiro
shap@cs.jhu.edu
Mon, 13 Nov 2000 11:50:56 -0500
Charles Landau wrote:
>
> Bill Frantz wrote:
>
> > I think the idea of getting/destroying domains with a space bank may be a
> > good one. The brand activity probably should be completely separated from
> > the space bank.
> >
> > One way to do this might be to make the brand slot a store-once slot/no
> > read. The domain would provide the store once operation. A separate
> > "brand tool" would provide the compare equal/not equal operation.
>
> The "brand tool" that you propose either is in cahoots with the space bank or it
> is not. If it is, you have not achieved any separation. If it is not, then it
> will fail to properly identify domains as implemented in my proposal
> <http://www.macslab.com/charlies/NoDC.html>, under the section "How extension
> would work under the proposal".
Your reasoning here does not match mine.
The brand tool is not necessarily in cahoots with the space bank. The
brand tool is in cahoots with the kernel concerning the process
abstraction. The branding mechanism should work only on a well-formed
process, and only the kernel is in a position to say officially whether
a process is well formed.
>From the wielder's perspective, there is a no trust relationship with
the space bank in *validating* a brand, because the test brand is not
disclosed by the brand tool. There *is* a trust relationship with the
space bank when a new brand is installed, because the space bank is in a
position to disclose the new brand by examining the node.
However, the question at hand is not whether there will be a distinct
brand tool capability. The question is who will wield it. If it is
wielded by the space bank, then the sequence of calls must be:
call to space bank: is this an X process
call to brand tool: is this an X process
return to space bank: yes/no
return to caller: yes/no
If the brand tool is directly held by the factory/constructor, then this
operation involves only a single kernel call and no context switches.
Separating them reduces the number of services that the space bank must
perform, and the space bank is already quite complex and its correctness
is utterly critical. Given that the power of the branding tool is a
subset of the power of a space bank validator that knows how to validate
brands, there is no amplification of authority from letting the
factory/constructor also hold the brand tool in addition to the space
bank. It already knows that the source of space is trusted by having
performed the "official space bank" check.
Given this engineering argument, I claim that the brand tool should
remain separate from the range tool. I feel that the risk and
performance reduction of moving branding to the bank has not yet been
adequately justified. My mind is certainly not closed on this, and
keeping the brand tool separate does not preclude moving this function
into the space bank as we go through our system building exercise.
Jonathan