Merge remote-tracking branch 'origin/master' into linux #1307
Conversation
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
Add module support in chakracore by adding related JSRT APIs. This set of APIs are in chakracore.dll only, not in chakra.dll as we are using different binding for edge browser. The host is responsible for asynchronously fetch dependent modules and handle error conditions. The overall loading sequences: host chakacore.dll 1. Load top level script 2. ----> JsInitializeModuleRecord // for root module 3. ----> JsParseModuleSource // parse root module 4. FetchImportedModuleCallback <---- // optional for imported module 5. -----> JsInitializeModuleRecord // for nested module 6. load additional script 7. -----> JsParseModuleSource // for nested module 8. NotifyModuleReadyCallback <----- 9. -----> JsModuleEvaluation // for root module step 4 to step 7 could be happening in a loop, and step 5 should happen asynchronously like in a Promise. Step 9 will also evaluate all the nested modules. Port some existing test cases to ch. We need to support test262 hook in later checkin.
Disable module tests in linux for now while I figure out why the import entries don't get resolved correctly in ch.
After the memop, we restore the induction variable to its expected value. If the memop didn't actually happen we shouldn't modify the induction variable. This is unlikely to happen since we would normally bailout on no profile and not emit this memop.
Enables us to pick up Chakra.Generated.BuildInfo.props so that we can set the binary version and file info correctly.
…ackgroundJobProcessor::DebugThreadNames Merge pull request chakra-core#1272 from ThomsonTan:FixDebugThreadName The missing colon makes the debug name incorrect after it.
…ory correctly in the environment. Merge pull request chakra-core#1186 from dilijev:objpath Enables us to pick up Chakra.Generated.BuildInfo.props so that we can set the binary version and file info correctly.
… ObjectDirectory correctly in the environment. Merge pull request chakra-core#1186 from dilijev:objpath Enables us to pick up Chakra.Generated.BuildInfo.props so that we can set the binary version and file info correctly.
Premise: acme-benchmark uses arguments[i] with typeof keyword. We do not currently optimize for this scenario. Change: Added support in the Globopt to enable Stack arg optimization when the function body has typeof keyword. Details: We optimistically insert (BailOnStackArgsOutOfActualsRange) for TypeOfElem, if it is a candidate for optimization. We decide during DeadStore phase, whether this bail out is required or not and then change the instr accordingly(as shown below). After GlobOpt Phase: Before: dst = TypeOfElem arguments[i] With this pack: tmpdst = LdElemI_A arguments[i] <(BailOnStackArgsOutOfActualsRange)> dst = TypeOf tmpdst Perf: This will help acme-benchmark by 3% as pointed out by Kunal.
…e Stack arg optimization Merge pull request chakra-core#1261 from satheeshravi:StackArgsTypeOf **Premise:** acme-benchmark uses arguments[i] with typeof keyword. We do not currently do Stack Arguments optimization for this scenario. **Change:** Added support in the Globopt to enable Stack arg optimization when the function body has typeof keyword. **Details:** We optimistically insert (BailOnStackArgsOutOfActualsRange) for TypeOfElem, if it is a candidate for optimization. We decide during DeadStore phase, whether this bail out is required or not and then change the instr accordingly(as shown below). **After GlobOpt Phase:** _Before:_ dst = TypeOfElem arguments[i] _With this pack:_ tmpdst = LdElemI_A arguments[i] <(BailOnStackArgsOutOfActualsRange)> dst = TypeOf tmpdst. **Perf:** This will help _acme-benchmark by 3%_ as pointed out by Kunal.
Premise: For strict mode, we start with a simple dictionary type for arguments object and transition to dictionary type upon adding setter/getter. This is costly. Fix: We, now, cache the dictionary type with accessors on the javascript library - so that we don't want to do the transition everytime. This improves the strict mode with arguments by 40% on micro benchmarks. Note that this will be evident only when stack arg optimization is disabled (because with optimization - we will not be creating the heap arguments object in the first place). Perf tests: Surprisingly, this code change didn't show up evidently in Speedometer - especially given the fact that there are some functions that have unoptimized heap arguments object. I am yet to try with acme-benchmark. IE PerfLab: (Few overall improvements in Elapsed/CPU Time) http://ieperf-web-01/perfresults/Comparison?testRunId=423952&baseRunId=423947&lab=IEPERF&getRelatedRunData=false&priorities=0,1&categories=failures,warnings,improvements,no-change&search= Note: SetAccessor API is still hot as most of the time is spent in GetPropertyName() -> which looks up the propertyRecord from the Dictionary. I kinda gave up at this point on further making strict mode scenario faster as the returns wasn't really fruitful. Let me know if someone has any thoughts on this.
… strict mode on the library Merge pull request chakra-core#1258 from satheeshravi:StackArgs_StrictMode1 **Premise:** For strict mode, we start with a simple dictionary type for arguments object and transition to dictionary type upon adding setter/getter. This is costly. **Fix:** We, now, cache the dictionary type with accessors on the javascript library - so that we don't want to do the transition everytime. _This improves the strict mode with arguments by 40% on micro benchmarks_. Note that this will be evident only when stack arg optimization is disabled (because with optimization - we will not be creating the heap arguments object in the first place). **Perf tests:** Surprisingly, this code change didn't show up evidently in Speedometer - especially given the fact that there are some functions that have unoptimized heap arguments object. I am yet to try with acme-benchmark. **IE PerfLab: (Few overall improvements in Elapsed/CPU Time)** http://ieperf-web-01/perfresults/Comparison?testRunId=423952&baseRunId=423947&lab=IEPERF&getRelatedRunData=false&priorities=0,1&categories=failures,warnings,improvements,no-change&search= **Note:** _SetAccessor API is still hot as most of the time is spent in GetPropertyName()_ -> which looks up the propertyRecord from the Dictionary. I kinda gave up at this point on further making strict mode scenario faster as the returns wasn't really fruitful. Let me know if someone has any thoughts on this.
Merge pull request chakra-core#1254 from Yongqu:bugfix Add module support in chakracore by adding related JSRT APIs. This set of APIs are in chakracore.dll only, not in chakra.dll as we are using different binding for edge browser. The host is responsible for asynchronously fetch dependent modules and handle error conditions. The overall loading sequences: ``` host chakacore.dll 1. Load top level script 2. ----> JsInitializeModuleRecord // for root module 3. ----> JsParseModuleSource // parse root module 4. FetchImportedModuleCallback <---- // optional for imported module 5. -----> JsInitializeModuleRecord // for nested module 6. load additional script 7. -----> JsParseModuleSource // for nested module 8. NotifyModuleReadyCallback <----- 9. -----> JsModuleEvaluation // for root module ``` step 4 to step 7 could be happening in a loop, and step 5 should happen asynchronously like in a Promise. Step 9 will also evaluate all the nested modules. Port some existing test cases to ch. We need to support test262 hook in later checkin.
…ypeSpec Merge pull request chakra-core#1277 from MikeHolman:nullhandler failedPropertyIndex is uninitialized in NullTypeHandler. it is used for tracing EquivObjTypeSpec, and causes a crash
After we change LdSlot instruction to Ld_A, the sym wasn't calling ProcessSymUse (in the DeadStore pass). ProcessSymUse marks the src sym as a nonTemp (which was being missed in this case - causing a cascade effect with boxing of number) Test: Running UTs.
…opertyKey to have no return value. Merge pull request chakra-core#1287 from jordonwii:issue1251_voidtopropertykey Fixes chakra-core#1251 It turned out the *only* place the return value of ToPropertyKey was used (that I could find) was where I saw it in chakra-core#1202. I changed the function signature to void, and removed the variable and the assert in that one place it was used.
…de of Conduct Merge pull request chakra-core#1177 from bterlson:new-coc Microsoft projects now have a unified code of conduct. This PR implements it by pointing to the document from the README.
Merge pull request chakra-core#1275 from Cellule:memop Bailout on Memset/Memcopy if the length is <= 0. After the memop, we restore the induction variable to its expected value. If the memop didn't actually happen we shouldn't modify the induction variable. This is unlikely to happen since we would normally bailout on no profile and not emit this memop.
… with formals Merge pull request chakra-core#1286 from satheeshravi:StackArgsBugFix1 After we change LdSlot instruction to Ld_A, the sym wasn't calling ProcessSymUse (in the DeadStore pass). ProcessSymUse marks the src sym as a nonTemp (which was being missed in this case - causing a cascade effect with boxing of number) Test: UTs pass. Exprgen looks fine.
This change combined fixes for CVE-2016-3259, CVE-2016-3260, CVE-2016-3265, CVE-2016-3269, CVE-2016-3271 and MS16-085. MSFT:7558512: [MSRC 33480] Mitigation Bypass Submission - InterpreterThunkEmitter Bypass CFG Issue. InterpreterStackFrame class has a member called interpreterThunk which stores the address of our interpreter function's address (regular or the asmjs one). The hacker took advantage of this address being stored in the heap memory and corrupted the same to reference a vulnerable shell code. We do not emit a CFG check for this address before calling, because this is a direct call and not an indirect call. Fix. This field is replaced with a boolean - to decide between regular/asmjs interpreter thunk. The address of the interpreter function is obtained in the function which is emitting the code, directly. This code has been present since the beginning - But this has to serviced only for chakra.dll (till th1), as we don't have CFG support before that. Tests. MSFT:7424216: [MSRC 33319] Chakra Type Confusion JavascriptArray::InternalCopyNativeFloatArrayElements - Individual [MSRC] Type confusion bug in ChakraCore JavascriptArray::InternalCopyNativeFloatArrayElements. MSFT:7527933: [MSRC 33383] Chakra JavascriptArray::ForEachOwnMissingArrayIndexOfObject - Individual [MSRC] Uninitialized stack variable in ChakraCore JavascriptArray::ForEachOwnMissingArrayIndexOfObject Component. Fix by ensuring stack variable was assigned before using. MSFT:7572196: [MSRC 33354] Edge Chakra ArrayBuffer.transfer - Zero Day Initiative Fix malloc/realloc usage in ES6 experimental feature ArrayBuffer.transfer. Should zero extra memory in either malloc or realloc case. MSFT:7387125 7387131 7387136 7387145 7387150 7424221 7424227: [MSRC 33299] Chakra Type Confusion in JavascriptArray::EntryFrom - Individual [MSRC] Type Confusion in Array built-ins DirectSetItemAt() is used in numerous Array built-ins without type-checking, where new objects may be created through a user-defined constructor. Fix by adding type-checking for type-specialized helper functions, and replacing DirectSetItemAt() calls with calls to virtual SetItem() functions where applicable. MSFT:7424474: [MSRC 33332] Edge ReadAV in chakra!Js::JavascriptOperators::StrictEqual+0x18 - Individual During sort prep we set orig[i] to missing_item. If an exception occurs in the middle (e.g. in "toString"), orig[i] will remain value missing_item, the Array's has_missing_item state could be wrong (wasn't updated), and the Array's content is also corrupted. Fixed by removing setting orig[i] to missing_item in prep. Do that after sort completion. (It is required to maintain segment length...end to contain only missing_item value.)
Merge pull request chakra-core#1291 from jianchun:pr1.2 This change combined fixes for CVE-2016-3259, CVE-2016-3260, CVE-2016-3265, CVE-2016-3269, CVE-2016-3271 and MS16-085. MSFT:7558512: [MSRC 33480] Mitigation Bypass Submission - InterpreterThunkEmitter Bypass CFG Issue. InterpreterStackFrame class has a member called interpreterThunk which stores the address of our interpreter function's address (regular or the asmjs one). The hacker took advantage of this address being stored in the heap memory and corrupted the same to reference a vulnerable shell code. We do not emit a CFG check for this address before calling, because this is a direct call and not an indirect call. Fix. This field is replaced with a boolean - to decide between regular/asmjs interpreter thunk. The address of the interpreter function is obtained in the function which is emitting the code, directly. This code has been present since the beginning - But this has to serviced only for chakra.dll (till th1), as we don't have CFG support before that. Tests. MSFT:7424216: [MSRC 33319] Chakra Type Confusion JavascriptArray::InternalCopyNativeFloatArrayElements - Individual [MSRC] Type confusion bug in ChakraCore JavascriptArray::InternalCopyNativeFloatArrayElements. MSFT:7527933: [MSRC 33383] Chakra JavascriptArray::ForEachOwnMissingArrayIndexOfObject - Individual [MSRC] Uninitialized stack variable in ChakraCore JavascriptArray::ForEachOwnMissingArrayIndexOfObject Component. Fix by ensuring stack variable was assigned before using. MSFT:7572196: [MSRC 33354] Edge Chakra ArrayBuffer.transfer - Zero Day Initiative Fix malloc/realloc usage in ES6 experimental feature ArrayBuffer.transfer. Should zero extra memory in either malloc or realloc case. MSFT:7387125 7387131 7387136 7387145 7387150 7424221 7424227: [MSRC 33299] Chakra Type Confusion in JavascriptArray::EntryFrom - Individual [MSRC] Type Confusion in Array built-ins DirectSetItemAt() is used in numerous Array built-ins without type-checking, where new objects may be created through a user-defined constructor. Fix by adding type-checking for type-specialized helper functions, and replacing DirectSetItemAt() calls with calls to virtual SetItem() functions where applicable. MSFT:7424474: [MSRC 33332] Edge ReadAV in chakra!Js::JavascriptOperators::StrictEqual+0x18 - Individual During sort prep we set orig[i] to missing_item. If an exception occurs in the middle (e.g. in "toString"), orig[i] will remain value missing_item, the Array's has_missing_item state could be wrong (wasn't updated), and the Array's content is also corrupted. Fixed by removing setting orig[i] to missing_item in prep. Do that after sort completion. (It is required to maintain segment length...end to contain only missing_item value.)
Merge pull request chakra-core#1291 from jianchun:pr1.2 This change combined fixes for CVE-2016-3259, CVE-2016-3260, CVE-2016-3265, CVE-2016-3269, CVE-2016-3271 and MS16-085. MSFT:7558512: [MSRC 33480] Mitigation Bypass Submission - InterpreterThunkEmitter Bypass CFG Issue. InterpreterStackFrame class has a member called interpreterThunk which stores the address of our interpreter function's address (regular or the asmjs one). The hacker took advantage of this address being stored in the heap memory and corrupted the same to reference a vulnerable shell code. We do not emit a CFG check for this address before calling, because this is a direct call and not an indirect call. Fix. This field is replaced with a boolean - to decide between regular/asmjs interpreter thunk. The address of the interpreter function is obtained in the function which is emitting the code, directly. This code has been present since the beginning - But this has to serviced only for chakra.dll (till th1), as we don't have CFG support before that. Tests. MSFT:7424216: [MSRC 33319] Chakra Type Confusion JavascriptArray::InternalCopyNativeFloatArrayElements - Individual [MSRC] Type confusion bug in ChakraCore JavascriptArray::InternalCopyNativeFloatArrayElements. MSFT:7527933: [MSRC 33383] Chakra JavascriptArray::ForEachOwnMissingArrayIndexOfObject - Individual [MSRC] Uninitialized stack variable in ChakraCore JavascriptArray::ForEachOwnMissingArrayIndexOfObject Component. Fix by ensuring stack variable was assigned before using. MSFT:7572196: [MSRC 33354] Edge Chakra ArrayBuffer.transfer - Zero Day Initiative Fix malloc/realloc usage in ES6 experimental feature ArrayBuffer.transfer. Should zero extra memory in either malloc or realloc case. MSFT:7387125 7387131 7387136 7387145 7387150 7424221 7424227: [MSRC 33299] Chakra Type Confusion in JavascriptArray::EntryFrom - Individual [MSRC] Type Confusion in Array built-ins DirectSetItemAt() is used in numerous Array built-ins without type-checking, where new objects may be created through a user-defined constructor. Fix by adding type-checking for type-specialized helper functions, and replacing DirectSetItemAt() calls with calls to virtual SetItem() functions where applicable. MSFT:7424474: [MSRC 33332] Edge ReadAV in chakra!Js::JavascriptOperators::StrictEqual+0x18 - Individual During sort prep we set orig[i] to missing_item. If an exception occurs in the middle (e.g. in "toString"), orig[i] will remain value missing_item, the Array's has_missing_item state could be wrong (wasn't updated), and the Array's content is also corrupted. Fixed by removing setting orig[i] to missing_item in prep. Do that after sort completion. (It is required to maintain segment length...end to contain only missing_item value.)
… bytecode layout to nightly config Merge pull request chakra-core#1285 from MikeHolman:bytecodeconfig
…e a BV node if the BV doesn't have a node that contains the bit we're testing. Changed the API so it doesn't create and instead returns early if it doesn't have the node we're looking for.
…ocate Merge pull request chakra-core#1297 from pleath:testandclear Fix a nit I found yesterday: SparseBitVector::TestAndClear will create a BV node if the BV doesn't have a node that contains the bit we're testing. Changed the API so it doesn't create and instead returns early if it doesn't have the node we're looking for.
The assert under interest was assuming that the Src1 of ArgOut Instr will always have a single def, which is false in some cases(the one which I observed was with PRE introducing extra defintion with this src sym)
…nternal property enumerating functions Merge pull request chakra-core#1298 from jordonwii:issue1252 Fixes chakra-core#1252 This adds strong return types (specifically, `JavascriptArray*`) to the following functions: In JavascriptOperators: 1. `JavascriptOperators::GetOwnPropertyNames` 2. `JavascriptOperators::GetOwnPropertySymbols` 3. `JavascriptOperators::GetOwnPropertyKeys` 4. `JavascriptOperators::GetOwnEnumerablePropertyNames` 5. `JavascriptOperators::GetOwnEnumerablePropertyNamesSymbols` The first 3 were mentioned in chakra-core#1252, and 4 and 5 had essentially the same structure - all 5 just returned one of either JavascriptProxy::PropertyKeysTrap or one of the \*PropertiesHelper functions on JavascriptObject (listed below), so I went ahead and gave *all* of them a strong return type, as well. In JavascriptObject (changed because the above all return the result of one of these): 1. `JavascriptObject::CreateOwnSymbolPropertiesHelper` 2. `JavascriptObject::CreateOwnStringPropertiesHelper` 3. `JavascriptObject::CreateOwnStringSymbolPropertiesHelper` 4. `JavascriptObject::CreateOwnEnumerableStringPropertiesHelper` 5. `JavascriptObject::CreateOwnEnumerableStringSymbolPropertiesHelper` 6. `JavascriptObject::CreateKeysHelper` The first 5 all return the result of 6). I had to update the signature of `JavascriptProxy::PropertyKeysTrap` to return `JavascriptArray*`, as well. This seemed correct, because a). most uses of it were followed by an assert that the result was a JavascriptArray, anyway, and b). [MDN says ](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/handler/ownKeys) the result of the ownKeys trap *must* be an array. The rest of the changes are removing asserts and simplifying and/or removing any code that checked the type of the result of calls to any of the above functions.
…rackInstrsForScopeObjectRemoval Merge pull request chakra-core#1296 from satheeshravi:StackArgsBugFix2 The assert under interest was assuming that the Src1 of ArgOut Instr will always have a single def, which is false in some cases(the one which I observed was with PRE introducing extra defintion with this src sym).
…Context::~ScriptContext+97 [d:\a\_work\19\s\core\lib\runtime\base\scriptcontext.cpp @ 378]) Fix an assert. ScriptContext dtor can be called if we failed half way during the intialization. Some perf improvement for ExternalFunctionThunk as it is the main entrypoint for external function calls. Get rid of unused ETW code, and move out DefaultEntryPoint check for DOM constructors that cannot be new'ed.
…library to encode surrogate pairs as UTF8 Merge pull request chakra-core#1303 from digitalinfinity:utf8_encoder
…T: isFinalized (Chakra!Js::ScriptContext::~ScriptContext+97 [d:\a\_work\19\s\core\lib\runtime\base\scriptcontext.cpp @ 378]) Merge pull request chakra-core#1302 from Yongqu:bugfix Fix an assert. ScriptContext dtor can be called if we failed half way during the intialization. Some perf improvement for ExternalFunctionThunk as it is the main entrypoint for external function calls. Get rid of unused ETW code, and move out DefaultEntryPoint check for DOM constructors that cannot be new'ed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 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.
No description provided.