[cap-talk] Announcing "Analysing Object-Capability Security" Paper and Authodox v. 0.2.0

[Jonathan S. Shapiro]

On Sat, 2008-05-31 at 02:22 +0100, David-Sarah Hopwood wrote:
> Jonathan S. Shapiro wrote:
> >   1. The opaqueness boundary at the OS/application layer is a problem,
> >      because it forces the OS to make mostly static, conservative
> >      assumptions about program behavior. For most programs this is fine,
> >      but there are two classes of important programs for which it is
> >      a problem:
> [...]
> >      B  Memoryless programs. There is a class of programs that require
> >         state for realistic implementations, but none of that state
> >         remains live when the program returns from a given request.
> >         The OS cannot see this. Functional programming doesn't help,
> >         because the compiled realization of a functional program is
> >         generally stateful.
> 
> I'd dispute that functional programming doesn't help here. It helps by
> providing a high-level programming model that does not depend on use of
> logically visible state.

The problem at hand is not whether the program was written using
stateful idiom. The problem is that the operating system needs to be
able to *observe* that no state is reachable on return in order to treat
the program as memoryless. It doesn't matter whether state was
introduced by the programmer or the compiler -- the OS cannot tell.

If a mechanism existed by which the OS *could* tell, then I agree that
functional programming might be useful, but I still believe that it is
the wrong approach for many of the things one would like to build.

> But suppose that the OS could snapshot the state of the process after
> an initialization phase, and then reset it to the snapshot after each
> application-level request....

This is a useful tool for thought experiments, but it is precisely the
implementation that we are trying to avoid. The OS, for example, has no
means to return the storage for the address space being abandoned.


shap