Hi Michael, the problem with any such mechanism is how to avoid corrupted state. The only consistent states for the heap, considered without the stack, are between turns when the stack is empty. Once a turn starts, it must be viewed as a transaction, to either roll forward to the end of turn committing the transaction, or roll back to the last inter-turn state, aborting the transaction. For the kinds of scenarios that Caja was built for, we could not afford the bookkeeping to roll back to beginning of turn, so there's no way to recover that vat from an infinite loop.
At Agoric we (together with Salesforce) have reconstructed SES for modern JavaScript at https://github.com/Agoric/SES . This is currently no better at coping with the issue you raise than is the old SES (SES5) component of Caja. However, one of our main motivating use cases is running SES on blockchains, where this issue becomes unavoidable. Fortunately, on blockchains, we can afford the bookkeeping needed for abortable transactions. To do the metering, we're planning to do a source-to-source rewrite inserting the equivalent of calls to your interceptor at least at function entries and loop body entries.This is essentially the approach ewasm takes to throttling wasm computations. Crucially, if the interceptor decides against continuing the computation, it does not throw an exception, as that would leave corrupted state. Instead it aborts the transaction, rolling back all effects that had happened so far during that turn. Unfortunately, until both of those bits of engineering are done --- the source-to-source rewrite and the abortable turn bookkeeping --- I can't offer any practical advice. On Sun, Oct 14, 2018 at 3:47 PM Michael FIG <[email protected]> wrote: > Hi, > > Thanks so much for Caja! It's exactly what I'm looking for to allow > client extensions to my platform. > > I was wondering if there is a way to have the host program provide an > interceptor for entering a function/backward branches (such as before > "continue" statements or just before the end for loops, while loops and > do...while loops). > > Basically, I would want this interceptor to be called every time we > execute non-linear code and either risk freezing the browser or blowing out > the stack. > > Then, I could have this interceptor either just return to allow the > execution or throw an exception to prevent the code from continuing to run. > > This would greatly extend the security of my Caja sandbox, and prevent one > of the main attacks I can forsee from my client code. > > while (true) { > // infinite loop > } > > or > > var j = 2; > for (var i = 0; i < j; i ++) { > j ++; > } > > or > > function loopme() { > part2(); > } > > function part2() { > part3(); > } > > function part3() { > loopme(); > } > > loopme(); > > Any advice would be much appreciated! > > Michael. > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Google Caja Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Cheers, --MarkM -- --- You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
