memory safety and weak references

David Bruant bruant.d at
Thu Mar 28 03:52:32 PDT 2013

[answering to different messages at once]
[cc'ing Oliver Hunt as Apple representative and Luke Hoban as Microsoft 
representative for questions at the bottom]

Le 27/03/2013 23:47, Brendan Eich a écrit :
> You have it backwards. You are advocating a GC design monoculture 
> (exact rooting only)
My point was that *some* implementations strategies don't have the issue 
and I pointed at one as an example. I wasn't implying it will/can/should 
be the only one. I'm open to other implementations that wouldn't use 
exact rooting, but wouldn't have the pointed security issue of 
conservative scanning. I'm open to any solution within the "memory-safe 
I probably won't be shocking anyone if I say that interpreting a number 
as a pointer is a bad idea? I think it's the first argument MarkM gives 
when he says that C++ isn't a memory-safe language.

Jason Orendorff wrote:
> Brendan's arguing for*more*  latitude for implementations to use different techniques.
I see. But clearly, the attack demonstrates that some implementation 
techniques (conservative scanning namely) have flaws. Maybe the latitude 
that goes up to accepting conservative scanning as an acceptable 
implementation technique isn't worth it as we want to see the language 

Brendan Eich wrote:
> ECMA-262 does not dictate GC design, and won't.
If TC39 makes a judgement call on what features can go in ECMA-262 or 
how they are designed based on what implementations are considered 
acceptable, then ECMA-262, by not having some features or having 
features design in a certain way carries an invisible weight that 
doesn't "dictate", but definitely drives implementors into making some 
choices (like keeping a conservative scanning GC).

[From the "Weak event listener" thread]
> Can you re-defend enumerability of weakmaps now that I've pointed out 
> the security risk does not apply only to SES users, to be addressed by 
> SES removing the @iterator? 
Just to clarify, I still feel (60%) against WeakRefs and enumerable 
WeakMaps/WeakSets. What I was defending was that if WeakRefs are in, 
then there is no reason to pretend making WeakMaps non-enumerable 
because of determinism, because the non-determinism brought by 
enumerable weakmaps isn't worse than the non-determinism brought by 
weakrefs (and I still need to answer Kevin Gadd's post).
That said, the security risk you pointed out is based on what I consider 
to be a flawed implementation (try implementing conservative stack 
scanning in a memory safe language like Rust), so assuming implementors 
are willing to admit conservative scanning is a bad idea and they plan 
to move away from it, WeakRefs and enumerable WeakMaps can still be 
discussed and their design can be freely discussed.
V8 has exact rooting, SpiderMonkey is getting there. As Sam pointed out, 
there are other incentives (generational GC?) for engines to get rid of 
conservative scanning (what an interesting non-coincidence :-) ). That's 
a lot of signal showing that implementors are moving away from 
conservative scanning.

I guess 2 relevant questions would be addressed directly to JSC and the 
IE team [cc'ing Oliver Hunt and Luke Hoban for that reason]: if you 
added weakrefs to your JS engine, would you be subject to the described 
attack? Do you have a plan to move away at some point in the future from 
your current implementation (to prevent the attack or whatever other 
good reason)? "at some point in the future", because the when is not 
important, but the intent really is.

If the answers are 'yes' and 'no' for one of the 2 JS engines, then only 
does TC39 have a problem with including Weakrefs to ECMA-262, I think.
I haven't read such a thing yet (did off-list/off-meeting notes 
discussion occur?), so let's wait until they bring these exact answers 
and then only either forget about WeakRefs until they change their mind 
or tweak the WeakRef design until it becomes something they'd accept to 
implement. But making one of these decisions before being forced to 
seems prematurate to me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list