Thank you, that makes perfect sense. Yes, I'm only concerned about defending my host code, which will be aware of this potential. I'll put together some simple tests that illustrate what I'm aiming for, and get back to the list when I have a strawman implementation completed.
But yes, I'm looking forward to the robust implementation MarkM has in mind! Many thanks, Michael. On Mon, Oct 15, 2018 at 8:47 AM Mike Stay <[email protected]> wrote: > On Sun, Oct 14, 2018 at 11:52 PM Michael FIG <[email protected]> wrote: > > > > Thanks for the speedy reply, Mark. > > > > On Sunday, October 14, 2018 at 9:05:27 PM UTC-6, MarkM wrote: > >> > >> 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. > > > > [...] > >> > >> 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. > > > > > > That's what I was planning. > > I'd recommend Babel for any source-to-source rewriting of javascript. > > >> 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. > > > > > > I'm not understanding why throwing an exception at the beginning of a > loop body or function call in a Javascript implementation can create > corrupted state. > > It has to do with security invariants of the code. Without explicit > throws, programmers don't think about the possibility of throwing an > exception at that point. There have even been attacks on javascript > code that measures the depth of the stack by recursing with a counter, > catching the resulting stack overflow error, and then invoking a > function at a certain stack depth so it throws an error in a critical > place. > > All that said, your particular use case may not care about the > security invariants of plugins, just the invariants of your own code. > If that's the case, then your plan may work. Be sure that any host > code that calls into guest code handles thrown exceptions properly. > -- > Mike Stay - [email protected] > http://math.ucr.edu/~mike > https://reperiendi.wordpress.com > > -- > > --- > You received this message because you are subscribed to a topic in the > Google Groups "Google Caja Discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/google-caja-discuss/swKiyyJ8hRw/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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.
