[cap-talk] controversial article

[Toby Murray]

On Tue, 2009-07-07 at 12:25 +0200, Matej Kosik wrote:
> I have added a conclusion where I try to summarize the possiblity to
> achieve defensive correctness also in other environments:
> 
> <conclusion>
> It was already
> shown~\cite{Shapiro03vulnerabilitiesin} how to
> achieve defensive correctness among concurrent
> processes interacting via synchronous rendezvous.
> The proposed updates of the Pict programming
> language enable us to achieve defensive
> correctness among concurrent processes
> interacting via asynchronous message-passing over
> channels. It is an open challenge how to update
> other programming languages supporting other
> programming paradigms (functional, procedural,
> object-oriented) in a similar way. In our work we
> are concerned with non-distributed software
> systems.  It is an open challenge how to define a
> platform for building defensively correct (or at
> least dependable with availability determined not
> by attackers but by inherent reliability of the
> network infrastructure) distributed software
> systems. Proposals for solutions would probably
> face serious problems caused by network effect
> which often represents a much stronger force than
> the desire for improved quality.
> </conclusion>
> 

I'm glad you mentioned Jonathan Shapiro's paper on Vulnerabilities in
Synchronous IPC designs. I was going to suggest that.

In fact, I would contend that your Pict mechanims are language-based
incarnations of the same ideas from these other platforms. In
particular, the memory accounting seems equivalent (if perhaps a bit
less expressive) than the KeyKOS/EROS space bank mechanism.

The donating send seems equivalent or similar to the "Trusted Buffer
Object" (although without requiring a separate object to implement as
the TBO does).

In this sense, the problems are no harder in the synchornous-rendevouz
case compared to the asynchronous-message-sending case. In fact, the
latter should be harder because it assumes some kind of buffering. In
Pict, for example, each time you send a message, you (effectively) need
to create a new thread. Hence, any spammer is also a cancer (adopting
your terminology here). The same is true for E from what MarkM has said
earlier in this thread because spamming causes memory consumption as
receive buffers fill up.

In the synchronous-rendevouz case, one can implement a spammer that is
not a cancer, however. I'm not sure if this is worth discussing.

If the similarities noted above between your work and Shapiro's are
valid, it might be worth mentioning the Shapiro paper somewhere before
the conclusion section -- probably either in the introduction or
specifically in a Related Work section.

Cheers

Toby