RESOLVED FIXED Bug 229559
Enable SharedArrayBuffer support when COOP/COEP headers are used
https://bugs.webkit.org/show_bug.cgi?id=229559
Summary Enable SharedArrayBuffer support when COOP/COEP headers are used
Chris Dumez
Reported 2021-08-26 08:44:23 PDT
Re-enable SharedArrayBuffer when COOP/COEP are used.
Attachments
WIP patch (4.38 KB, patch)
2021-08-26 08:55 PDT, Chris Dumez
no flags
WIP patch (6.24 KB, patch)
2021-08-26 09:13 PDT, Chris Dumez
no flags
WIP patch (10.05 KB, patch)
2021-08-26 09:37 PDT, Chris Dumez
no flags
WIP patch (42.31 KB, patch)
2021-08-26 11:24 PDT, Chris Dumez
ews-feeder: commit-queue-
WIP patch (44.54 KB, patch)
2021-08-26 14:57 PDT, Chris Dumez
no flags
WIP patch (47.99 KB, patch)
2021-08-26 15:49 PDT, Chris Dumez
no flags
WIP patch (52.15 KB, patch)
2021-08-26 16:48 PDT, Chris Dumez
no flags
WIP patch (now with API tests) (72.83 KB, patch)
2021-08-27 09:47 PDT, Chris Dumez
no flags
WIP patch (68.71 KB, patch)
2021-08-27 10:06 PDT, Chris Dumez
no flags
Patch (82.27 KB, patch)
2021-08-27 12:23 PDT, Chris Dumez
no flags
Patch (90.09 KB, patch)
2021-08-27 14:43 PDT, Chris Dumez
no flags
Patch (90.80 KB, patch)
2021-08-27 17:00 PDT, Chris Dumez
no flags
Patch (101.83 KB, patch)
2021-08-30 08:09 PDT, Chris Dumez
no flags
Patch (102.55 KB, patch)
2021-08-31 13:21 PDT, Chris Dumez
no flags
Patch (102.81 KB, patch)
2021-08-31 16:01 PDT, Chris Dumez
no flags
Radar WebKit Bug Importer
Comment 1 2021-08-26 08:44:46 PDT
Chris Dumez
Comment 2 2021-08-26 08:55:44 PDT
Created attachment 436515 [details] WIP patch
Chris Dumez
Comment 3 2021-08-26 09:13:14 PDT
Created attachment 436517 [details] WIP patch
Chris Dumez
Comment 4 2021-08-26 09:37:46 PDT
Created attachment 436527 [details] WIP patch
Chris Dumez
Comment 5 2021-08-26 11:24:21 PDT
Created attachment 436535 [details] WIP patch
Chris Dumez
Comment 6 2021-08-26 14:57:41 PDT
Created attachment 436573 [details] WIP patch
Chris Dumez
Comment 7 2021-08-26 15:49:53 PDT
Created attachment 436580 [details] WIP patch
Yusuke Suzuki
Comment 8 2021-08-26 15:54:35 PDT
*** Bug 218944 has been marked as a duplicate of this bug. ***
Chris Dumez
Comment 9 2021-08-26 16:48:26 PDT
Created attachment 436588 [details] WIP patch
Yusuke Suzuki
Comment 10 2021-08-26 18:45:32 PDT
*** Bug 218943 has been marked as a duplicate of this bug. ***
Chris Dumez
Comment 11 2021-08-27 09:47:07 PDT
Created attachment 436636 [details] WIP patch (now with API tests)
Chris Dumez
Comment 12 2021-08-27 10:06:51 PDT
Created attachment 436639 [details] WIP patch
Chris Dumez
Comment 13 2021-08-27 12:23:38 PDT
Chris Dumez
Comment 14 2021-08-27 14:43:30 PDT
Chris Dumez
Comment 15 2021-08-27 17:00:10 PDT
Ryosuke Niwa
Comment 16 2021-08-27 21:10:00 PDT
Comment on attachment 436694 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=436694&action=review > Source/WebCore/loader/DocumentLoader.cpp:957 > + if (currentCoopEnforcementResult->crossOriginOpenerPolicy.value == CrossOriginOpenerPolicyValue::SameOriginPlusCOEP) > + return NeedsBrowsingContextGroupSwitch::YesWithCrossOriginIsolation; > + return NeedsBrowsingContextGroupSwitch::YesWithoutCrossOriginIsolation; How about BrowsingContextGroup::StayInGroup BrowsingContextGroup::NewSharedGroup BrowsingContextGroup::NewIsolatedGroup > Source/WebKit/UIProcess/WebProcessProxy.h:136 > + enum class IsCrossOriginIsolated : bool { No, Yes }; How about enum class CrossOriginMode : bool { Shared, Isolated };
Chris Dumez
Comment 17 2021-08-30 08:09:48 PDT
Alex Christensen
Comment 18 2021-08-31 12:20:32 PDT
Comment on attachment 436772 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=436772&action=review > Source/WebKit/ChangeLog:24 > + JSC Options need to be set before JSC::initialize() is called, which occurs This doesn't seem to be true with the code. It seems to be set immediately after JSC::initialize but before other things. > Source/WebCore/dom/ScriptExecutionContext.cpp:84 > +static CrossOriginMode globalCrossOriginMode { CrossOriginMode::Shared }; Since this is written to by the main thread and read from by multiple threads, should it be std::atomic? Right now it's written only during process initialization, so it's probably no big deal. > Source/WebCore/loader/DocumentLoader.cpp:954 > + return BrowsingContextGroup::StayInGroup; I think BrowsingContextGroup isn't a great name for this. It's more of a policy action than a group, which makes me think of PageGroup or some other kind of container. "BrowsingContextGroupSwitchDecision" or something > Source/WebCore/page/DOMWindow.idl:-82 > - // FIXME: Implement 'originIsolated' So I guess this isn't a thing any more, replaced by window.crossOriginIsolated, right? > Source/WebKit/Shared/WebProcessCreationParameters.h:139 > + WebCore::CrossOriginMode crossOriginMode { false }; // Cross-origin isolation via COOP+COEP headers. false is the wrong type. I think this should be { WebCore::CrossOriginMode::CrossOriginMode } > Source/WebKit/UIProcess/WebProcessProxy.h:446 > + bool shouldEnableSharedArrayBuffer() const final { return m_crossOriginMode == WebCore::CrossOriginMode::Isolated; } Will there be other uses of this? We may want to do other things like increase the resolution of DOMHighResTimeStamp. I think this should be called isCrossOriginIsolated(), but no strong feelings. It is currently used for enabling SharedArrayBuffer. > LayoutTests/imported/w3c/web-platform-tests/html/cross-origin-embedder-policy/cross-origin-isolated-permission.https-expected.txt:5 > +FAIL frame: origin = https://localhost:9443, value = (\) assert_equals: expected false but got true Why did this used to pass and it now fails?
Chris Dumez
Comment 19 2021-08-31 12:30:17 PDT
Comment on attachment 436772 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=436772&action=review >> Source/WebKit/ChangeLog:24 >> + JSC Options need to be set before JSC::initialize() is called, which occurs > > This doesn't seem to be true with the code. It seems to be set immediately after JSC::initialize but before other things. I did what Mark Lam suggested and it is working. I think my changelog is just wrong. Will fix. >> Source/WebCore/dom/ScriptExecutionContext.cpp:84 >> +static CrossOriginMode globalCrossOriginMode { CrossOriginMode::Shared }; > > Since this is written to by the main thread and read from by multiple threads, should it be std::atomic? Right now it's written only during process initialization, so it's probably no big deal. As you said, it is only set during process initialization so I don't think this is strictly necessary. >> Source/WebCore/loader/DocumentLoader.cpp:954 >> + return BrowsingContextGroup::StayInGroup; > > I think BrowsingContextGroup isn't a great name for this. It's more of a policy action than a group, which makes me think of PageGroup or some other kind of container. > "BrowsingContextGroupSwitchDecision" or something OK, I had one naming in my original patch (NeedsBrowsingContextGroupSwitch { No, YesWithCrossOriginIsolation, YesWithoutCrossOriginIsolation }; But Ryosuke didn't like it so I went with the exact naming he suggested. >> Source/WebCore/page/DOMWindow.idl:-82 >> - // FIXME: Implement 'originIsolated' > > So I guess this isn't a thing any more, replaced by window.crossOriginIsolated, right? Right, replaced by self.crossOriginIsolated. >> Source/WebKit/Shared/WebProcessCreationParameters.h:139 >> + WebCore::CrossOriginMode crossOriginMode { false }; // Cross-origin isolation via COOP+COEP headers. > > false is the wrong type. I think this should be { WebCore::CrossOriginMode::CrossOriginMode } Oops, indeed. Got it wrong when I did the renaming that Ryosuke suggested. >> Source/WebKit/UIProcess/WebProcessProxy.h:446 >> + bool shouldEnableSharedArrayBuffer() const final { return m_crossOriginMode == WebCore::CrossOriginMode::Isolated; } > > Will there be other uses of this? We may want to do other things like increase the resolution of DOMHighResTimeStamp. I think this should be called isCrossOriginIsolated(), but no strong feelings. It is currently used for enabling SharedArrayBuffer. I already have a follow-up patch almost ready for DOMHighResTimeStamp. That patch will rely on ScriptExecutionContext::crossOriginMode() since it is in WebCore. >> LayoutTests/imported/w3c/web-platform-tests/html/cross-origin-embedder-policy/cross-origin-isolated-permission.https-expected.txt:5 >> +FAIL frame: origin = https://localhost:9443, value = (\) assert_equals: expected false but got true > > Why did this used to pass and it now fails? I explained in the changelog. This test relies on Permissions-Policy HTTP header (https://w3c.github.io/webappsec-permissions-policy/) which we don't support. We used to pass by luck because self.crossOriginIsolated was returning false unconditionally.
Chris Dumez
Comment 20 2021-08-31 12:34:43 PDT
Comment on attachment 436772 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=436772&action=review >>> Source/WebKit/ChangeLog:24 >>> + JSC Options need to be set before JSC::initialize() is called, which occurs >> >> This doesn't seem to be true with the code. It seems to be set immediately after JSC::initialize but before other things. > > I did what Mark Lam suggested and it is working. I think my changelog is just wrong. Will fix. My code seems correct, so does the changelog. According to Mark Lam, I need to set the option *after* calling JSC::Options::initialize() but *before* JSC::initialize() is called.
Alex Christensen
Comment 21 2021-08-31 12:40:53 PDT
Oh, you're right. JSC::initialize and JSC::Options::initialize are different things.
Chris Dumez
Comment 22 2021-08-31 13:21:55 PDT
Chris Dumez
Comment 23 2021-08-31 16:01:19 PDT
EWS
Comment 24 2021-08-31 16:53:24 PDT
Committed r281832 (241165@main): <https://commits.webkit.org/241165@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 436957 [details].
Note You need to log in before you can comment on or make changes to this bug.