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

[Kevin Reid]

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.

> 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.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>