Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0220229336674e16179554f590e10644e4e021fd
https://github.com/WebKit/WebKit/commit/0220229336674e16179554f590e10644e4e021fd
Author: Yusuke Suzuki <[email protected]>
Date: 2025-06-11 (Wed, 11 Jun 2025)
Changed paths:
M Source/JavaScriptCore/llint/InPlaceInterpreter.asm
M Source/JavaScriptCore/llint/InPlaceInterpreter.cpp
M Source/JavaScriptCore/llint/InPlaceInterpreter.h
M Source/JavaScriptCore/llint/InPlaceInterpreter32_64.asm
M Source/JavaScriptCore/llint/InPlaceInterpreter64.asm
M Source/JavaScriptCore/llint/LowLevelInterpreter.asm
M Source/JavaScriptCore/runtime/JSCConfig.h
Log Message:
-----------
[JSC] Harden IPInt dispatch
https://bugs.webkit.org/show_bug.cgi?id=294344
rdar://153095450
Reviewed by Keith Miller.
Relanding Keith's change with some fixes for x64. In x64, we cannot
directly get label address, so instead of doing it, we store them into
JSCConfig and load it.
This patch hardens how IPInt dispatches opcodes for better CFI protection.
Since IPInt does an offset based
dispatch the previous dispatch was something like:
```
macro dispatchToNextIPIntInstruction()
// x7 is set to _ipInt_instruction_base on entry to IPInt entry/call return.
loadb [PC], x0
emit "add x0, x7, x0, lsl #8"
emit "br x0"
end
align 256
_ipint_dispatch_base:
.first_wasm_bytecode:
// stuff
dispatchToNextIPIntInstruction()
align 256
.second_wasm_bytecode:
// stuff
dispatchToNextIPIntInstruction()
...
align 256
.255_wasm_bytecode:
// stuff
dispatchToNextIPIntInstruction()
```
In the old system no matter what value [PC] points to there are 256 offsets
reachable, all of which are
either a valid opcode or a slab of `brk`s.
However, this still means if an attacker is able to return to the IPInt
interpreter on some path that
doesn't reset x7 then they'll be able to implement a JOP attack. One example
would be to build a fake
object with a vtable pointing to one of the "C function" labels (e.g.
_first_wasm_bytecode_validate,
which is used for offset validation).
After this change dispatch is now:
```
macro dispatchToNextIPIntInstruction()
loadb something, x0
pcrtoaddr _ipint_dispatch_base, x7
emit "add x0, x7, x0, lsl #8"
emit "br x0"
end
```
which makes it clearly impossible to get a PAC bypass in IPInt dispatch. Since
there's no longer
a semi-pinned register with the base pointer this patch removes all that
associated code.
Additionally, this change adds a names for all the dispatch starts to make the
code a bit easier to read.
Lastly, the SIMD prefix opcode was missing a security guard so this patch adds
that too.
* Source/JavaScriptCore/llint/InPlaceInterpreter.asm:
* Source/JavaScriptCore/llint/InPlaceInterpreter.cpp:
(JSC::IPInt::initialize):
* Source/JavaScriptCore/llint/InPlaceInterpreter.h:
* Source/JavaScriptCore/llint/InPlaceInterpreter32_64.asm:
* Source/JavaScriptCore/llint/InPlaceInterpreter64.asm:
* Source/JavaScriptCore/llint/LowLevelInterpreter.asm:
* Source/JavaScriptCore/runtime/JSCConfig.h:
Canonical link: https://commits.webkit.org/296121@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
