WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
148136
Add InternalPromise to use Promises safely in the internals
https://bugs.webkit.org/show_bug.cgi?id=148136
Summary
Add InternalPromise to use Promises safely in the internals
Yusuke Suzuki
Reported
2015-08-18 12:36:35 PDT
https://bugs.webkit.org/show_bug.cgi?id=147942
solve the part of the problem. But, since resolving function always looks up "then" function, by setting malicious "then" function, we can still trap it... To make Promises safe, we'll introduce new constructor/prototype set for InternalPromise. That is the separated instance from the usual Promise.
Attachments
Patch
(78.20 KB, patch)
2015-08-18 22:32 PDT
,
Yusuke Suzuki
no flags
Details
Formatted Diff
Diff
Patch
(78.13 KB, patch)
2015-08-18 22:39 PDT
,
Yusuke Suzuki
saam
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Yusuke Suzuki
Comment 1
2015-08-18 22:32:27 PDT
Created
attachment 259357
[details]
Patch
Yusuke Suzuki
Comment 2
2015-08-18 22:39:29 PDT
Created
attachment 259358
[details]
Patch
Yusuke Suzuki
Comment 3
2015-08-18 22:55:45 PDT
Module Loader spec requires the use of the Promise internally. So we need some user-non-trappable Promises.
Yusuke Suzuki
Comment 4
2015-08-18 22:57:02 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
> Source/JavaScriptCore/ChangeLog:29 > + to the user space.
The largest concern is this.
Yusuke Suzuki
Comment 5
2015-08-19 00:28:07 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
>> Source/JavaScriptCore/ChangeLog:29 >> + to the user space. > > The largest concern is this.
One mitigation for the leak problem is 1. freezing InternalPromise.prototype 2. prevent InternalPromise instance extension But they raise performance concerns I guess.
Yusuke Suzuki
Comment 6
2015-08-19 01:21:39 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
> Source/JavaScriptCore/ChangeLog:8 > + This patch implements InternalPromise.
First, I planed to fix the issue by adding @promiseInternal flag to the existing Promise instance to switch the behavior of the Promise operations. This will make the modification small. However, if we take the above way, it breaks the Promises implementation's one-on-one correspondence to the spec. And when the spec is changed, we need to change the existing code so much carefully not to break the internal promise system. I think that's not good. So I changed my mind. That's why I introduced completely separately instantiated InternalPromises in this patch.
Yusuke Suzuki
Comment 7
2015-08-19 11:33:19 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
> Source/JavaScriptCore/runtime/JSInternalPromiseDeferred.h:49 > + JSInternalPromise* promise() const;
I'll add JS_EXPORT_PRIVATE later.
Yusuke Suzuki
Comment 8
2015-08-19 20:22:51 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
> Source/JavaScriptCore/ChangeLog:21 > + the returned promise by "then" method, we construct the chain by executing `p2.then(resolving function)`.
Misleading, "the returned promise by "then" method" means `p3 = p1.then(...)`'s p3.
Saam Barati
Comment 9
2015-08-19 20:43:00 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
r=me
> Source/JavaScriptCore/runtime/JSInternalPromiseConstructor.cpp:38 > +STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE(JSInternalPromiseConstructor);
Nit: Why not have this in below namespace?
> Source/JavaScriptCore/runtime/JSPromise.h:52 > + // This may raises the JS exception.
"raises the" => "raise a"
Yusuke Suzuki
Comment 10
2015-08-19 21:07:23 PDT
Comment on
attachment 259358
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=259358&action=review
Thank you!
>> Source/JavaScriptCore/runtime/JSInternalPromiseConstructor.cpp:38 >> +STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE(JSInternalPromiseConstructor); > > Nit: Why not have this in below namespace?
Originally, this namespace is the place to 1. locate `STATIC_ASSERT_IS_TRIVIALLY_DESTRUCTIBLE(JSInternalPromiseConstructor);` 2. locate the forward declarations for C++ JS methods that will become the property of the focused object (like arrayPrototypeFuncJoin etc.) In the case of this file, there's no C++ JS method. So just (1) remains. (2) should be locate here because it should be declared before including "JSInternalPromiseConstructor.lut.h" (this can be included in the global namespace), but (1) can be locate after the "JSInternalPromiseConstructor.lut.h". So I'll move this before the JSInternalPromiseConstructor::s_info line.
>> Source/JavaScriptCore/runtime/JSPromise.h:52 >> + // This may raises the JS exception. > > "raises the" => "raise a"
Thanks! Fixed.
Yusuke Suzuki
Comment 11
2015-08-19 21:43:31 PDT
Committed
r188681
: <
http://trac.webkit.org/changeset/188681
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug