[EROS-Arch] Re: [Cap-Talk] Re: (process tool restriction)

[Jonathan S. Shapiro]

Charles Landau wrote:

> Not really. Today, an errant process creator can create malformed processes. In
> the proposal, an errant space bank can do so. In KeyKOS the kernel did not
> trust the space bank, and one can argue it shouldn't in EROS either.

I claim that the distinction between the kernel and the space
bank/process creator for the purposes of trust is a null distinction. To
the application, both of these things are in the minimal possible TCB.
No reasonable system can be built without trusting both the source of
storage and the source of processes.

Once these things are both in the minimal TCB, there remain engineering
reasons for them to make minimal assumptions of each other, but not
security reasons.

In this case, there are arguments on both sides. The kernel should not
trust the space bank as a matter of good engineering paranoia. On the
other hand, if the space bank is busted it doesn't really matter much if
the kernel works, since the whole system is pretty well busted as a
result.

There is a cost to distrusting the space bank, which is that the kernel
must perform consistency checks at run time that the space bank is able
to perform at creation time.

I am therefore partial to a middle-ground approach, in which the
creation of a process capability is done by making a kernel invocation
from the space bank, and that this kernel operation performs the process
consistency checks, invalidates any outstanding node capabilities to the
constituents, and creates a well-formed process (i.e. any register
values that the protection system depends on are properly set). It is
then possible to remove the well-formedness check from the process
encache code, because no outside process holds sufficient capability
authority to invalidate the well-formedness of the process.

> > then we have a problem, because the space for the process came
> > from the end user and might be used for multiple different programs. If the
> > replacement is to give the space bank [the] brand and say "does this process
> > match
> > this brand"
> 
> that is my proposal

The concern here is that we must know that the space bank is an official
space bank or this is unsafe. However, I see no issue here that is
different from the problems that arise in the "are you a valid bank"
test.

There is an assumption in here that there is ultimately only one real
space bank, and that one space bank can therefore perform checks on the
yield of another, but I don't see this as a major problem.

In fact, I'ld suggest that this operation be made part of the space bank
validator. We actually do have one of those -- it's a capability to a
descendant of the prime space bank with a zero limit.

Sold.