The Anthropic Side Channel (was: How would shallow generators compose with lambda?)

Brendan Eich brendan at mozilla.com
Thu May 21 10:41:29 PDT 2009


On May 16, 2009, at 11:25 AM, Mark S. Miller wrote:

> On Fri, May 15, 2009 at 2:26 PM, Brendan Eich <brendan at mozilla.com>  
> wrote:
>> [...] but plain old iloop DOS prevention as practiced in browsers
>> does *not* reload the page. And the browser APIs are full of  ways  
>> to detect
>> that finallys didn't run, through effects overt and covert.
>> [...]
>> Just consider iloop DOS prevention as practiced in browsers today:  
>> finally
>> may not run. That's enough.
>
> Have you tried this lately? In a squarefree shell on several browser  
> I typed in
>
>  var x = 8; try { while (true) {} } finally { x = 7; }
>
> Results:
>
> Safari promped. I told it to "stop" scripts. Afterwards, the event was
> terminated, but scripts on the page were still able to run. x was 7,
> indicating that finallys were executed on the way out.

Seems like an exception (possibly uncatchable?) was thrown.


> IE: Similar, but x was 8 indicating that no finallys were run.
>
> FF, Opera, Chrome: That squarefree shell remained hung and I never got
> prompted, even after leaving these to run overnight. I am surprised. I
> have not heard of this behavior.

Not sure what's up there -- which version of Firefox? Also, you can  
run that code in a javascript: URL typed directly into the address  
bar, or into the Error Console's text input.

I just entered

javascript:var x = 8; try { while (true) {} } finally { x = 7; }; void 0

into the address bar in Firefox 3.5 pre-release, and after ten seconds  
(we use wall time to watchdog scripts) I got the slow script dialog.  
Clicking Stop then terminated the loop, and as with IE, the finally  
ran, as

javascript:alert(x)

confirmed by alerting 8 not 7.

The IE and Firefox policy is meant to stop the script for good.  
Running finallys might just re-iloop, leading to the slow script  
dialog, user picks Stop, finallys run, ad infinitum:

javascript:var x = 8; (function f() { try { while (true) {} } finally  
{ x = 7; f(); } })(); void 0

An implementation supporting tail call optimization wouldn't grow its  
stack so the stack growth limiting done by quality implementations ;-)  
would not save you.

This seems a good reason not to run finallys.

The same issue came up with our attempts to automate generator close  
from the GC, as Python does. This is a no-no in browsers. In other  
embeddings, it could be desirable, but it overconstrains the  
implementation (CPython uses refcounting with cycle GC, and the prompt  
finalization is expected by programmers).

/be


More information about the es-discuss mailing list