[e-lang] Fwd: @RISK: Sun Java Floating-Point Value Denial of Service

[Thomas Leonard]

On 07/02/11 15:54, Kevin Reid wrote:
> On Feb 7, 2011, at 10:13, Thomas Leonard wrote:
>
>> On 5 February 2011 13:07, Kevin Reid<kpreid at switchb.org>  wrote:
>>> DoS is out of scope for E, in general.
>>
>> There are different levels of DoS, though. It seems reasonable that
>> code running within a vat can stop it from responding. Also, handling
>> a very large number of requests from clients might make it slow. But,
>> if the clients stop sending messages then the vat should recover, I
>> think.
>
> That would be nice, and I've had that idea myself, but there's far too
> many ways to jam up a vat using incoming messages.
>
> (Old thread with MarkM's comments:
> <http://www.eros-os.org/pipermail/e-lang/2003-August/008915.html>.
> Note that in the third message I bring up exactly your point. )
>
> If we were to eliminate pipelining and mobile code, such that the
> client is obligated to handle the computation of every object which is
> not far from it, and the interface of every single exported object was
> carefully designed so it is O(N) in input message size, even in the
> face of misbehaving arguments, except where required by the
> application -- then perhaps a vat could be made DoS-safe.

The O(N) requirement might not be necessary. For messages to our own 
objects, we typically record some usage (and we could therefore abort if 
limits are reached). e.g.

def bubbleSort {
   to sort(l : List) {
     reserve(l.size() ** 2)
     return l.sort()
   }
}

The main problem is that operations on primitive types (e.g. int) can 
generate unlimited amounts of usage without any checks.

>> Can we somehow block highly expensive operations on common data types?
>
> Where would you enforce such restrictions? If you add them to the data
> types, you make it harder to program locally. And CapTP isn't in a
> position to know what 'data type' is being invoked in order to
> selectively reject operations.
>
>> I guess we'd need to ban PassByConstruction by default too.
>
> Everything that isn't an atom or a far ref is PassByConstruction.
> You're not going to get very much useful communication that way.

I'm not quite sure what the right term is, but generally we only send 
the kind of things you could send in SOAP or JSON (numbers, strings, 
lists, maps, sets, etc), plus promises, SturdyRefs and references.

A protocol that could handle that, with pipelining, would be fine. I 
don't see how to do it, though.


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk