memory safety and weak references

Oliver Hunt oliver at apple.com
Mon Apr 1 13:37:19 PDT 2013


There are numerous problems with weak references and primitives, mostly revolving around the ability to regenerate a primitive, e.g.

    someWeakRef.set("foo")
    gc()
    var something = "foo"
    someWeakRef.get() // null or "foo"?

 vs.

    someWeakRef.set("foo")
    var something = "foo"
    gc()
    someWeakRef.get() // null or "foo"?

vs.

    someWeakRef.set("foo")
    var something = "fo"
    something += "o"
    gc()
    someWeakRef.get() // null or "foo"?

And of course all this just becomes worse for numeric primitives -- All existing engines use tagged values for some set of numeric values, and can also end up with the same value stored in different ways.  V8 (at least in 32bit) gc allocates doubles, but not a subset of integers, this means that if you get the value 1 as a double then it might be gc'd and so the weak ref could go away, but if it were in the tagged int form it would not.

JSC doesn't immediately intern strings, but over time duplicates do get merged, at which point weakness starts acquiring odd behaviour.  Because off the implicitly shared heap in different pages this may even be exploitable as a way to find out information about other pages (essentially the weak reference to a primitive allows a side channel for determining content of other pages that you would not otherwise have access to)

This means that any consistent semantic for primitives results in useless behaviour - either the weak ref has to be (essentially) strong on primitives, or be cleared on ever gc() regardless of "liveness" of other references.

--Oliver


On Apr 1, 2013, at 1:22 PM, Marius Gundersen <gundersen at gmail.com> wrote:

> This seems to be more a problem with the garbage collector than with weak references. If I understood it correctly, any double value can look like a pointer, and the garbage collector will check what it is pointing at. To me this seems like a source for memory leaks. This problem exists even without weak references (or weak iterable maps/sets); the weak references just makes it observable. Does this mean the main reason weak references (or, again, weak iterable maps/sets) are not to be implemented is because of a bug in the garbage collector of popular JS enginges? As noted earlier, the implementation of the garbage collector is not specified in the ecmascript standard, so this is a problem with implementors, not with the specification. 
> 
> Again, I'm far from an expert on GC or JS implementations (and would love a simplified explanation if I have misunderstood the problem), but this seems less like a problem with weak references, and more like a problem with specific implementations of GCs. 
> 
> Marius Gundersen
> 
> 
> On Fri, Mar 29, 2013 at 3:47 AM, Oliver Hunt <oliver at apple.com> wrote:
> 
> On Mar 29, 2013, at 7:36 AM, David Herman <dherman at mozilla.com> wrote:
> 
> > On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> >
> >> On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt <oliver at apple.com> wrote:
> >>> That said I believe that this does kill any dreams i may have had w.r.t primitive-keyed WeakMaps, kudos to MarkM.
> >>
> >> Wouldn't a primitive-keyed WeakMap just be a strong Map for those
> >> keys?  And therefore immune to any GC attacks?
> >
> > Indeed, and also deeply misleading (a weak map with strongly held entries?), which is why I argued that WeakMap should disallow primitive keys.
> >
> > Oliver-- can you clarify what you were hoping for?
> 
> I was dreaming of primitive keys, i was convinced in an earlier meeting of the problems that they would cause, but this security problem is a nail in the coffin :-/
> 
> >
> > Dave
> >
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130401/fc539c62/attachment.html>


More information about the es-discuss mailing list