memory safety and weak references
brendan at mozilla.com
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.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss