[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
monoculture".
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
evolve.
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.
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
