[cap-talk] Resource exhaustion - a language level issue?
smagi at higherlogics.com
Tue Oct 9 21:49:37 EDT 2007
Jed Donnelley wrote:
> On 10/9/2007 11:39 AM, Sandro Magi wrote:
>> I'm talking about isolation between two entities on the *same* system,
>> not different systems. If subsystem A is perfectly isolated from
>> subsystem B (no capability path between them except via the kernel),
>> then an attack in B should have no visible effect in A. With a DoS, this
>> is not the case.
> Hmmm. I took "isolation" to mean none other than authorized
> communication. When I consider such communication I include
> only direct data channels and do not include typical "covert
> channels" such as wall banging. I understand the definitions
> of others may be different.
Reasoning about authority, ie. the ability to cause effects, is what
we're interested in. If the ability to mount an attack is ambient (as
visible by a DoS), then that indicates a resource that needs to be more
adequately protected. So I think that it's more useful to say that any
DoS opportunity is really a resource that is insufficiently protected.
So I understand what you're trying to say, but I don't think classifying
this as covert vs. overt is useful in this case, since the covert abuse
is so easy, and so ambient that it should really be an overt resource.
EROS/KeyKOS manage memory over overt channels for instance; capability
languages still have implicitly managed memory handled by the "kernel",
which is why they're still vulnerable to DoS; there may be some implicit
memory management technique to remedy this, which is what that thread is
> I don't see any reason in principle that equivalent OS
> level primitives can't be supplied at the language level.
> However, there may be legitimate overhead concerns.
Overhead can be made practically nonexistent. See Erlang for instance,
or Microsoft's Singularity project for a more striking example.
Language-level processes are as expensive as a function call in
principle, which is considerably lighter than a real OS process.
More information about the cap-talk