[cap-talk] Domain change (IPC?) overhead

[Jonathan S. Shapiro]

On Tue, 2008-03-25 at 12:12 -0700, David Wagner wrote:
> Jonathan Shapiro writes:
> >The domain scale that I am discussing is the one that conceptually
> >replaces processes. At that boundary crossing, sharing and storage
> >isolation become important issues. None of the systems that you identify
> >above address this issue. IIRC, E chose not to address storage isolation
> >explicitly.
> 
> Most current desktop and server OS's effectively don't address those
> issues, either.  If one process decides to go hog wild and monopolize
> all shared resources (e.g., all CPU), my OS will basically let it do so.
> They don't even take care of accounting.
> 
> One possible interpretation of this state of affairs: people don't
> consider storage isolation, accounting, and scheduling to be a
> particularly important or critical security mechanism.
> 
> The above is deliberately intended as a "devil's advocate" view to try
> to expand my understanding.  What do you think?

For desktop applications I think you are mostly correct. There do exist
controls in the minimal sense that non-root users cannot allocate the
last bit of swap space or file system space, but that seems like rather
cold comfort.

However, it is not conceptually difficult to imagine augmenting UNIX
with a provisioning scheme that would resolve this. There are two key
simplifying points:

  1. There are no cycles in the UNIX resource reference graph.
  2. Absent a parent/child hierarchy relationship, there is in practice
     no reference sharing across processes. I_SENDFD exists, but to
     first order it is not used. This tends to preserve storage
     isolation.

Finally, note that I'm not in the desktop business, so even if what you
say is entirely true, I don't consider that a good reason to abandon the
issue from the perspective of sound system design. The broader, more
interesting issue that you raise, and that MarkM raised indirectly, is
that not all domain boundaries need to guard all issues. DeepCopy
boundaries might be something one wants to state explicitly.

Which raises the question: is DeepCopy a type or a qualifier?

Interesting.

shap