[cap-talk] Resource exhaustion (was: Horton vs. ACLs)
Sandro Magi
smagi at higherlogics.com
Mon Oct 8 20:27:23 EDT 2007
Jed Donnelley wrote:
> On 10/8/2007 10:38 AM, Mark Miller wrote:
>> For ocap systems like KeyKOS, EROS, CapROS, Coyotos, GuardOS where
>> right to memory is a first class right and the kernel does no implicit
>> allocation, we do not yet have practical proposals for membrane
>> mechanisms, whether for use by Horton or even for non-kernel remoting
>> systems like DCCS. I have heard no proposal for non-kernel remoting
>> systems that are invulnerable to memory exhaustion attacks.
>
> Thanks for clarifying that MarkM. When you refer to memory
> exhaustion attacks I assume you are referring to attacks that
> result in denial of service - e.g. vs. breaking access control.
I'm not sure. A system vulnerable to denial of service (DoS) attacks
violates isolation guarantees; isolation is needed to properly reason
about authority (causality), so I think there is some overlap.
> I now remember a bit about these resource exhaustion attacks
> being mentioned before. Perhaps I don't take such attacks
> seriously enough. To me the scope of denial of service attacks
> that involve resource exhaustion are so broad and so serious
> in existing market leading systems, that I tend to place them
> into a category of "we'll worry about those issues when they
> come to the top of the list" - e.g. a bit like covert channels
> such as wall banging with regard to confinement.
DoS attacks are a severe problem in a local system. I agree they are
less of an issue for a networked system because of the more restricted
bandwidth. Resource exhaustion is also a far greater danger than covert
channels, and we see the negative effects of improper resource
management all the time (more so than cover channels to be sure).
Here was discussion on memory accounting for garbage collected languages
we had back in June:
http://www.eros-os.org/pipermail/cap-talk/2007-June/007940.html
I was trying to hash out a set of primitives for implicitly allocating
/GC'd languages so they could thwart such resources exhaustion attacks.
Sorry if the thread is a little long-winded. :-)
Sandro
More information about the cap-talk
mailing list