At
https://esdiscuss.org/topic/memory-safety-and-weak-references#content-1
Dave Herman wrote
> Interestingly, I wonder if the idea of only collecting weak references
> between turns is immune to such attacks, since it's not possible to
> have a bogus reference on the stack between turns, where
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
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()
Marius Gundersen 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,
No, that's not the issue in this (sub-)thread. Oliver was just
recollecting thoughts about a position he took
There are numerous problems with weak references and primitives, mostly
revolving around the ability to regenerate a primitive, e.g.
The issue about non-object WeakMap keys was about semantics only, not
implementation safety bugs. If I can put 42 in a WeakMap, it can never be
removed, since I
Marius Gundersen wrote:
This is why I suggested, in the other thread, a system for weak event
listeners. This would not be a problem if the only allowed argument to
a weak reference is a function. An iterable weak set of functions
would not have this problem, would solve the suggested usecases
: Re: memory safety and weak references
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
-discuss-boun...@mozilla.org [mailto:
es-discuss-boun...@mozilla.org] *On Behalf Of *Oliver Hunt
*Sent:* Monday, April 01, 2013 4:37 PM
*To:* Marius Gundersen
*Cc:* es-discuss discussion
*Subject:* Re: memory safety and weak references
** **
There are numerous problems with weak references
Hudson, Rick wrote:
This brings up another interesting point. Do WeakRefs change a
compiler’s liveness analysis?
Yes, of course.
This could complicate some apparently useful optimizations.
{
var x = new Something();
someWeakRef.set(x);
// Is x dead? (yes) Is x required to contribute
On Mon, Apr 1, 2013 at 2:56 PM, Brendan Eich bren...@mozilla.com wrote:
Hudson, Rick wrote:
This brings up another interesting point. Do WeakRefs change a compiler’s
liveness analysis?
Yes, of course.
This could complicate some apparently useful optimizations.
{
var x = new
(); is allowed to
return null.
- Rick
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Monday, April 01, 2013 5:56 PM
To: Hudson, Rick
Cc: Oliver Hunt; Marius Gundersen; es-discuss discussion
Subject: Re: memory safety and weak references
Hudson, Rick wrote
; Marius Gundersen; es-discuss discussion
Subject: Re: memory safety and weak references
Hudson, Rick wrote:
This brings up another interesting point. Do WeakRefs change a
compiler's liveness analysis?
Yes, of course.
This could complicate some apparently useful optimizations.
{
var
On Apr 1, 2013, at 3:12 PM, Hudson, Rick rick.hud...@intel.com wrote:
If the compiler can prove x does not escape the block and it is not used
again then it is dead and the compiler is free to reuse the stack slot
holding the last reference.
So I am arguing that x = null; is not required
: memory safety and weak references
On Apr 1, 2013, at 3:12 PM, Hudson, Rick
rick.hud...@intel.commailto:rick.hud...@intel.com wrote:
If the compiler can prove x does not escape the block and it is not used again
then it is dead and the compiler is free to reuse the stack slot holding
to use an optimization. I
just wanted to make it clear that one could.
-Rick
*From:*Oliver Hunt [mailto:oli...@apple.com]
*Sent:* Monday, April 01, 2013 6:18 PM
*To:* Hudson, Rick
*Cc:* Brendan Eich; Marius Gundersen; es-discuss discussion
*Subject:* Re: memory safety and weak references
On Apr 1
[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
On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@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
On Mar 29, 2013, at 7:36 AM, David Herman dher...@mozilla.com wrote:
On Mar 27, 2013, at 4:52 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@apple.com wrote:
That said I believe that this does kill any dreams i may have had w.r.t
On Tue, Mar 26, 2013 at 11:44 PM, Oliver Hunt oli...@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
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
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
On Wed, Mar 27, 2013 at 4:53 PM, David Bruant bruan...@gmail.com wrote:
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
Interestingly, I wonder if the idea of only collecting weak references between
turns is immune to such attacks, since it's not possible to have a bogus
reference on the stack between turns, where there is no stack.
Dave
On Mar 26, 2013, at 5:55 PM, David Herman dher...@mozilla.com wrote:
David Herman wrote:
Patrick Walton send me this link to a fascinating approach to exploiting weak
references in engines using conservative stack scanning to discover the address
of objects:
https://github.com/justdionysus/gcwoah
I don't fully grok all the details, but IIUC the attacker
Brendan Eich wrote:
Dion did the JITSpray paper at BlackHat 2010:
This paper is very hard to find now! I downloaded a copy, but I'm not
sure about protocol. Breadcrumbs that time out for me are at
http://www.woodmann.com/forum/archive/index.php/t-13412.html
/be
25 matches
Mail list logo