Wpe 2.38 backport hardening add bounds check to string view operator#1673
Open
aoikonomopoulos wants to merge 5 commits intoWebPlatformForEmbedded:wpe-2.38from
Conversation
…g/show_bug.cgi?id=244903 rdar://99644213 Reviewed by Alexey Shvayka and Justin Michaud. According to the spec[1], TypedArray has an ability to stop [[Prototype]] traversing for numeric index string (e.g. "0.1"). Thus we should align IC's traversing to this behavior, which is already implemented in JSObject::getPropertySlot. This patch threads property name and we check this abruption in prototype traversing code for IC if structure is TypedArray. [1]: https://262.ecma-international.org/9.0/#_ref_2826 * JSTests/stress/poly-proto-typed-array-case.js: Added. (bar.Foo): (bar): * Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp: (JSC::generateConditionsForPropertyMiss): (JSC::generateConditionsForPropertySetterMiss): (JSC::generateConditionsForIndexedMiss): (JSC::generateConditionsForPrototypePropertyHit): (JSC::generateConditionsForPrototypePropertyHitCustom): (JSC::generateConditionsForInstanceOf): (JSC::generateConditionsForPrototypeEquivalenceConcurrently): (JSC::generateConditionsForPropertyMissConcurrently): (JSC::generateConditionsForPropertySetterMissConcurrently): (JSC::prepareChainForCaching): * Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h: * Source/JavaScriptCore/bytecode/PolyProtoAccessChain.cpp: (JSC::PolyProtoAccessChain::tryCreate): * Source/JavaScriptCore/bytecode/PolyProtoAccessChain.h: * Source/JavaScriptCore/bytecode/Repatch.cpp: (JSC::tryCacheGetBy): (JSC::tryCacheArrayGetByVal): (JSC::tryCachePutBy): (JSC::tryCacheInBy): (JSC::tryCacheInstanceOf): * Source/JavaScriptCore/llint/LLIntSlowPaths.cpp: (JSC::LLInt::setupGetByIdPrototypeCache): * Source/JavaScriptCore/runtime/JSGenericTypedArrayViewInlines.h: (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot): (JSC::JSGenericTypedArrayView<Adaptor>::put): (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty): (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty): * Source/JavaScriptCore/runtime/JSObjectInlines.h: (JSC::JSObject::getNonIndexPropertySlot): * Source/JavaScriptCore/runtime/PropertyName.h: (JSC::isCanonicalNumericIndexString): * Source/JavaScriptCore/runtime/StructureRareData.cpp: (JSC::StructureRareData::cacheSpecialPropertySlow): Canonical link: https://commits.webkit.org/254264@main
… not a number https://bugs.webkit.org/show_bug.cgi?id=259230 rdar://112292849 Reviewed by Alexey Shvayka. This patch makes isCanonicalNumericIndexString early return for obvious non number cases so that we avoid super costly number-to-string & string-to-number path. * Source/JavaScriptCore/runtime/PropertyName.h: (JSC::isCanonicalNumericIndexString): Canonical link: https://commits.webkit.org/266080@main
…webkit.org/show_bug.cgi?id=259664 rdar://113162575 Reviewed by Mark Lam. This makes less conservative on isCanonicalNumericIndexString. We only care "Infinity" and "NaN" cases here. * JSTests/stress/typed-array-canonical.js: Added. (shouldBe): * Source/JavaScriptCore/runtime/PropertyName.h: (JSC::isCanonicalNumericIndexString): Canonical link: https://commits.webkit.org/266460@main
…ow_bug.cgi?id=263491 Reviewed by Darin Adler. Add bounds check to StringView::operator[] and StringView::charactersAt() as a hardening measure. This patch was initialized a performance regression on Speedometer and Jetstream. I used a profiler to find the call sites in hot code path and moved them away from StringView::operator[]. As it stands, this patch is performance-neutral on Speedometer and Jetstream on the various hardware models I A/B tested on. * Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp: (JSC::toDouble): (JSC::jsToNumber): * Source/JavaScriptCore/runtime/JSStringJoiner.cpp: (JSC::appendStringToData): (JSC::joinStrings): (JSC::JSStringJoiner::joinSlow): * Source/JavaScriptCore/runtime/PropertyName.h: (JSC::fastIsCanonicalNumericIndexString): (JSC::isCanonicalNumericIndexString): * Source/WTF/wtf/text/StringImpl.h: (WTF::StringImpl::span8 const): (WTF::StringImpl::span16 const): * Source/WTF/wtf/text/StringView.h: (WTF::StringView::characterAt const): (WTF::StringView::unsafeCharacterAt const): (WTF::StringView::CodeUnits::Iterator::operator* const): (WTF::findCommon): Canonical link: https://commits.webkit.org/269630@main
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Template
File a Bug
All changes should be associated with a bug. The WebKit project is currently using Bugzilla as our bug tracker. Note that multiple changes may be associated with a single bug.
Provided Tooling
The WebKit Project strongly recommends contributors use
Tools/Scripts/git-webkitto generate pull requests. See Setup and Contributing Code for how to do this.Template
If a contributor wishes to file a pull request manually, the template is below. Manually-filed pull requests should contain their commit message as the pull request description, and their commit message should be formatted like the template below.
Additionally, the pull request should be mentioned on Bugzilla, labels applied to the pull request matching the component and version of the Bugzilla associated with the pull request and the pull request assigned to its author.
b3f3ddf