[e-lang] Fwd: @RISK: Sun Java Floating-Point Value Denial of Service
kpreid at switchb.org
Mon Feb 7 07:54:43 PST 2011
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
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:
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/>
More information about the e-lang