I've made some initial stabs:
https://bugs.webkit.org/show_bug.cgi?id=27276
The bindings need a bunch more cleanup before we can do much more than
that. I've started filing bugs about the cleanup.
On Tue, Jul 14, 2009 at 12:41 PM, Geoffrey Garen wrote:
>>> Also, once we've established the model,
Also, once we've established the model, we'll need to propose it to
some
standards body -- probably HTML5.
I believe the correct spec to describe this behavior is WebIDL, which
controls how the abstract DOM interfaces are realized in ECMAScript.
Sounds good.
Geoff
__
On Tue, Jul 14, 2009 at 12:31 PM, Geoffrey Garen wrote:
> Also, once we've established the model, we'll need to propose it to some
> standards body -- probably HTML5.
I believe the correct spec to describe this behavior is WebIDL, which
controls how the abstract DOM interfaces are realized in ECMA
That's correct. Other browser's get this case right. Here are a
couple test cases you might find interesting:
http://webblaze.org/abarth/tests/protoconfused/test1.html
http://webblaze.org/abarth/tests/protoconfused/test2.html
I tried these tests, with mixed results:
IE8: Exception thrown dur
On Jul 13, 2009, at 5:34 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiak
wrote:
If security is one motivation for this work, then I'd like us to
understand
the pattern we want to use for cross-origin-accessible objects.
Should they
use the "home global object" prot
On Mon, Jul 13, 2009 at 4:59 PM, Maciej Stachowiak wrote:
> If security is one motivation for this work, then I'd like us to understand
> the pattern we want to use for cross-origin-accessible objects. Should they
> use the "home global object" prototype but protect it from mutation or
> access to
On Jul 13, 2009, at 4:34 PM, Adam Barth wrote:
CVE-2009-1702 is an example of such as security hole. I'm sure that I
can find more if I look for them.
I think objects attached to the global object and accessible cross-
origin are a special case here. (The advisory cited is about Location
On Mon, Jul 13, 2009 at 4:20 PM, Maciej Stachowiak wrote:
> My own interest would be in weighing the tradeoffs. In the Pro column:
>
> 1) Are there aspects of this issue that create security holes?
CVE-2009-1702 is an example of such as security hole. I'm sure that I
can find more if I look for t
On Jul 13, 2009, at 4:11 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garen
wrote:
That's correct. Other browser's get this case right. Here are a
couple test cases you might find interesting:
http://webblaze.org/abarth/tests/protoconfused/test1.html
http://webblaze.org/
On Jul 13, 2009, at 4:12 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiak
wrote:
Built-in classes work somewhat differently. I believe they use the
calling
function's global object ("lexical global object") rather than
having some
notion of home object.
You might
On Mon, Jul 13, 2009 at 4:08 PM, Maciej Stachowiak wrote:
> Built-in classes work somewhat differently. I believe they use the calling
> function's global object ("lexical global object") rather than having some
> notion of home object.
You might be thinking of boxing primitive values, which do in
On Jul 13, 2009, at 3:40 PM, Adam Barth wrote:
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garen
wrote:
Our current behavior is buggy, unpredictable, and out of spec. This
has led to security bugs in the past and will lead to security
bugs in
the future.
I don't disagree with you, but I'm
On Mon, Jul 13, 2009 at 4:01 PM, Geoffrey Garen wrote:
>> That's correct. Other browser's get this case right. Here are a
>> couple test cases you might find interesting:
>>
>> http://webblaze.org/abarth/tests/protoconfused/test1.html
>> http://webblaze.org/abarth/tests/protoconfused/test2.html
>
Consider this case, which does not involve a DOM object:
frames[0].Array.prototype.push.__proto__ ==
Array.prototype.push.__proto__
Built-in classes work somewhat differently. I believe they use the
calling function's global object ("lexical global object") rather
than having some notion
On Jul 13, 2009, at 3:36 PM, Geoffrey Garen wrote:
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState (close
Yep... My guess is that (a) is probably better, but you two are more
expert on why we use lazy construction.
Heh -- lazy construction in JSC is even older than I am! :)
The goal is to reduce memory use and startup cost in cases where
certain functions aren't used. I'm not sure how much of a
Which spec did you have in mind? I'd like to read it.
Essentially, the ECMAScript spec requires this. In spec-land, these
objects are all created at the beginning of time. The fact that we
create them lazily is what leads to this bug. Depending on who
touches them first, they end up with diff
On Mon, Jul 13, 2009 at 3:36 PM, Geoffrey Garen wrote:
> Sam and I just noticed that, to fully support this behavior, any host object
> that lazily constructs function properties using the functions in lookup.h
> must either
>
> (a) change in the same way as DOM objects must change
>
> or
>
> (b) e
On Mon, Jul 13, 2009 at 3:29 PM, Geoffrey Garen wrote:
>> Our current behavior is buggy, unpredictable, and out of spec. This
>> has led to security bugs in the past and will lead to security bugs in
>> the future.
>
> I don't disagree with you, but I'm not immediately convinced that a large
> des
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState (close to you #1). I would
not advocate storing more data
Is there a particular security or other benefit here, or do we just
want to
make this change to match other browsers?
Our current behavior is buggy, unpredictable, and out of spec. This
has led to security bugs in the past and will lead to security bugs in
the future.
I don't disagree with
On Mon, Jul 13, 2009 at 2:26 PM, Maciej Stachowiak wrote:
> For the few cases where
> cross-origin access is allowed, we would *not* want to expose the home
> window's prototype chain. So for Window.postMessage for instance,
> cross-origin access need to give you a distinct wrapper.
That's correct
On Mon, Jul 13, 2009 at 1:33 PM, Geoffrey Garen wrote:
>>> Is it definitely right for document.body to make a wrapper using
>>> prototypes
>>> from the document's host window, rather than from the accessing
>>> function's
>>> window? What do other browsers do?
>>
>> That's correct. Other browser's
On Jul 13, 2009, at 2:36 PM, Maciej Stachowiak wrote:
Don't you need an ExecState to report exceptions, including the
uncatchable out-of-memory exception? Or does that work differently
now?
It works differently now. A JSGlobalData is all you need to report
exceptions.
-- Darin
On Jul 13, 2009, at 2:28 PM, Geoffrey Garen wrote:
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState (close
I discussed this a bit with Darin and Geoff, and we came to the
conclusion
that the correct fix is to have each JS DOMObject store a
JSGlobalObject
pointer and augment the toJS methods to pass a global object
instead of an
ExecState (close to you #1).
There are classes in JavaScriptCore wi
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store
a JSGlobalObject pointer and augment the toJS methods to pass a
global object instead of an ExecState (close to you #1).
You probably mean "in addition to" rath
On Jul 13, 2009, at 2:18 PM, Sam Weinig wrote:
I discussed this a bit with Darin and Geoff, and we came to the
conclusion that the correct fix is to have each JS DOMObject store a
JSGlobalObject pointer and augment the toJS methods to pass a global
object instead of an ExecState (close t
1. Pass a "current global object" through to all toJS calls (lots of
callsites changed)
2. Store a "current global object" off of the ExecState (set by the
JS engine before leaving into custom native code for property lookup
or function execution).
I discussed this a bit with Darin and Geoff,
On Mon, Jul 13, 2009 at 2:18 PM, Sam Weinig wrote:
> I discussed this a bit with Darin and Geoff, and we came to the conclusion
> that the correct fix is to have each JS DOMObject store a JSGlobalObject
> pointer and augment the toJS methods to pass a global object instead of an
> ExecState (close
On Mon, Jul 13, 2009 at 1:57 PM, Eric Seidel wrote:
> On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen wrote:
> > I'm not sure what you guys have been meaning by the phrase "correct
> heap."
> > Barring workers, all WebCore objects are allocated from the same heap.
>
> We had wrongly assumed that
On Mon, Jul 13, 2009 at 1:36 PM, Geoffrey Garen wrote:
> I'm not sure what you guys have been meaning by the phrase "correct heap."
> Barring workers, all WebCore objects are allocated from the same heap.
We had wrongly assumed that each window got its own. OK. This
invalidates using heaps as a
I'm first fixing JSCell::new subclasses to make sure they're always
allocating in the correct heap. If we're to map from objects to the
associated globalobject via the heap, we need to fix allocation
first.
I'm not sure what you guys have been meaning by the phrase "correct
heap." Barring w
Is it definitely right for document.body to make a wrapper using
prototypes
from the document's host window, rather than from the accessing
function's
window? What do other browsers do?
That's correct. Other browser's get this case right.
Is there a particular security or other benefit he
Our current thinking is to add a parameter to toJS() to receive the
JSGlobalObject in which to create the wrapper.
Seems logical.
Once we do that, the question is how to find the proper
JSGlobalObject at each call site.
In most cases, you have another JSObject sitting around that is from
t
Re-sending from correct address.
On Mon, Jul 13, 2009 at 1:23 PM, Eric Seidel wrote:
> I'm looking at this more today.
>
> I'm first fixing JSCell::new subclasses to make sure they're always
> allocating in the correct heap. If we're to map from objects to the
> associated globalobject via the he
1. Is it correct for the ExecState to carry the "thisValue"?
As Adam realized later (I think), ExecState carries the value for
"this" inside the calling function. It does not carry the object whose
property is being accessed.
Geoff
___
webkit-de
On Fri, Jul 10, 2009 at 6:29 PM, Maciej Stachowiak wrote:
> On Jul 10, 2009, at 6:10 PM, Adam Barth wrote:
>> That's correct. Other browser's get this case right. Here are a
>> couple test cases you might find interesting:
>>
>> http://webblaze.org/abarth/tests/protoconfused/test1.html
>> http://
(Trimming Cc's since the relevant people are on webkit-dev anyway.)
On Jul 10, 2009, at 6:10 PM, Adam Barth wrote:
On Fri, Jul 10, 2009 at 6:04 PM, Maciej Stachowiak
wrote:
Is it definitely right for document.body to make a wrapper using
prototypes
from the document's host window, rather
Sent again from the right address. Gmail hates me today.
On Fri, Jul 10, 2009 at 6:10 PM, Adam Barth wrote:
> On Fri, Jul 10, 2009 at 6:04 PM, Maciej Stachowiak wrote:
>> On Jul 10, 2009, at 5:55 PM, Adam Barth wrote:
>>> Eric and I spent some more time this afternoon looking at this. We
>>> don
On Jul 10, 2009, at 5:55 PM, Adam Barth wrote:
Eric and I spent some more time this afternoon looking at this. We
don't think the ExecState::thisValue() approach is going to work. We
implemented hacky version to experiment with, but the problem is with
cases like this:
document.body
In eval
Re-sent with correct address.
On Fri, Jul 10, 2009 at 5:55 PM, Adam Barth wrote:
> Eric and I spent some more time this afternoon looking at this. We
> don't think the ExecState::thisValue() approach is going to work. We
> implemented hacky version to experiment with, but the problem is with
> c
Geoff, Gavin, Sam, Maciej (and any other JSC experts):
Adam and I are fixing:
https://bugs.webkit.org/show_bug.cgi?id=27088
Fix: toJS needs to use the correct global object. The correct global
object should come from whatever "this" is calling into the native
code which is using toJS.
(e.g. docu
43 matches
Mail list logo