[cap-talk] Resource exhaustion - a language level issue?
Jed Donnelley
jed at nersc.gov
Tue Oct 9 13:49:15 EDT 2007
On 10/8/2007 5:27 PM, Sandro Magi wrote:
> 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;
Why do you believe so? A system that has been impacted by a
denial of service attack is not available (by definition),
so the isolation is perfect - isn't it?
> isolation is needed to properly reason about authority (causality),
I agree with that, but as noted above not that freedom from
denial of service attack is necessary for isolation.
> so I think there is some overlap.
Sorry, I don't yet see it.
>> 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. :-)
I read through the above. I certainly agree with:
"if A and B are unrelated hierarchically, ownership is assigned
randomly to A or B. This seems like it could be problematic for
asymmetric trust relationship."
I also agree with this from the paper you reference:
"Operating systems account for memory consumption and
allow for termination at the level of individual processes.
As a result, if one process consumes too much memory, it
can be terminated without damaging the rest of the system.
This same capability can be useful within a single application
that encompasses subtasks."
and I would go beyond "can be useful" to 'seems to me
necessary' - just as it is at the OS level. If trust
boundaries are going to be enforced at the language
level then all the mechanisms required at the OS level I
believe are needed at the language level. To even
distinguish a "language level" seems a bit odd as the
enforcements that one associates with a trusted computing
base needs to be there at the language level if trust
boundaries are to be trustworthy.
I think I'm finally starting to get a feel for the issue
that you and Jonathan seem to be addressing.
I wonder if it might be best for me to just drop out of
the discussion at this point. I don't have enough experience
with language level enforcement of trust boundaries to
contribute significantly. From my perspective all
objects should be "accounted" for. To not do so seems
to me to go beyond lazy (which as with most programmers
I consider a virtue) to incomplete - which I of course
view as unacceptable. However, I can well accept the
criticism that any comment by me along those lines is
necessarily ignorant and overstated.
I'll try to just leave it by agreeing (to the extent my
higher level OS experience is relevant) with what I believe
some are saying that to offer a complete trust solution
(mutual suspicion between objects) I believe storage
'accounting' is needed.
--Jed http://www.webstart.com/jed/
More information about the cap-talk
mailing list