memory safety and weak references

Brendan Eich brendan at
Wed Mar 27 15:47:06 PDT 2013

You have it backwards. You are advocating a GC design monoculture (exact 
rooting only) as an assumption informing a security analysis that must 
take into account both language features (enumerable weakmaps; weak 
references) *and* implementation vulnerabilities across a large space of 
different implementation strategies.

ECMA-262 does not dictate GC design, and won't.

Dave's observation about turn-based weak-ref notification seems worth 
considering more deeply, though. I don't think Oliver's numeric-type 
stack value puns a weak ref issue necessarily disposes of the idea that 
an engine with a conservative stack scanner, combined with weak 
references and turn-based notification, would be safe against attacks of 
the kind Dionysus demonstrated. NaN-boxing engines can't generally have 
such controllable wild NaNs in double-typed stack slots, AFAIK.


David Bruant wrote:
> Le 27/03/2013 01:55, David Herman a écrit :
>> But we need to take this into account as we consider what to do about 
>> weak references in ES7.
> From what I understand, doing exact rooting (instead of conservative 
> stack scanning) solves the problem or more precisely prevents the 
> attack by design (because the attack would be based on numbers being 
> interpreted as pointers addresses).
> Assuming I understand correctly (and tell me if I don't), this is more 
> an attack based on an implementation detail than an attack based on 
> the inclusion of a weak references to the language, so I'm puzzled as 
> to why this attack should be taken into account when discussing the 
> inclusion of weak references.
> Over the last month after Opera announced moving to WebKit, people on 
> Twitter have been rounds and rounds about Webkits monoculture and how 
> making spec decisions based on specific implementations is a bad thing 
> ("if specs followed WebKit implementation, we couldn't have parallel 
> rendering engines like Servo", etc.). I don't see why that could be a 
> good thing at the ECMAScript level.
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at

More information about the es-discuss mailing list