Fix v8 crashes on Apple mobile platforms (iOS/WatchOS/tvOS)

[hexploitable]

Since Frida 16.0 introduced snapshots, the v8 backend has been crashing on both jailed and jailbroken devices due to snapshots trying to use RWX memory. E.g.:

• can't use to // runtime='v8' frida#3561
• Frida 16.6.6 fails to spawn on iOS 13.3 when using v8 runtime frida#2544
• iOS crashes after startup when using the —runtime v8 parameter frida#2449

Crash:

<--- Last few GCs --->

<--- JS stacktrace --->

#
# Fatal javascript OOM in Executable MemoryChunk allocation failed during deserialization.
#

(lldb) bt
* thread #7, name = 'gum-js-loop', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1071e8594)
  * frame #0: 0x00000001071e8594 FridaGadget.dylibv8::base::OS::Abort() + 32
    frame #1: 0x0000000106e9274c FridaGadget.dylibv8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, v8::OOMDetails const&) + 164
    frame #2: 0x0000000106e92680 FridaGadget.dylibv8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, v8::OOMDetails const&) + 608
    frame #3: 0x0000000106fa5c84 FridaGadget.dylibv8::internal::Heap::FatalProcessOutOfMemory(char const*) + 32
    frame #4: 0x0000000106fe7e94 FridaGadget.dylibv8::internal::MemoryAllocator::HandleAllocationFailure(v8::internal::Executability) + 72
    frame #5: 0x0000000106fe7e04 FridaGadget.dylibv8::internal::MemoryAllocator::AllocateAlignedMemory(unsigned long, unsigned long, unsigned long, v8::internal::Executability, void*, v8::internal::VirtualMemory*) + 404
    frame #6: 0x0000000106fe80a8 FridaGadget.dylibv8::internal::MemoryAllocator::AllocateUninitializedChunk(v8::internal::BaseSpace*, unsigned long, v8::internal::Executability, v8::internal::PageSize) + 116
    frame #7: 0x0000000106fe85f8 FridaGadget.dylibv8::internal::MemoryAllocator::AllocatePage(v8::internal::MemoryAllocator::AllocationMode, v8::internal::Space*, v8::internal::Executability) + 148
    frame #8: 0x0000000106ff65f0 FridaGadget.dylibv8::internal::PagedSpaceBase::TryExpandImpl() + 48
    frame #9: 0x0000000106ff7864 FridaGadget.dylibv8::internal::PagedSpaceBase::TryExpand(int, v8::internal::AllocationOrigin) + 52
    frame #10: 0x0000000106ff7508 FridaGadget.dylibv8::internal::PagedSpaceBase::RawRefillLabMain(int, v8::internal::AllocationOrigin) + 1360
    frame #11: 0x0000000106ff6fa4 FridaGadget.dylibv8::internal::PagedSpaceBase::RefillLabMain(int, v8::internal::AllocationOrigin) + 44
    frame #12: 0x0000000106f9e548 FridaGadget.dylibv8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) + 368
    frame #13: 0x0000000106f9ee1c FridaGadget.dylibv8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) + 56
    frame #14: 0x00000001071eca5c FridaGadget.dylibv8::internal::Heap::AllocateRawOrFail(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) + 724
    frame #15: 0x00000001071ec1cc FridaGadget.dylibv8::internal::Deserializer<v8::internal::Isolate>::Allocate(v8::internal::AllocationType, int, v8::internal::AllocationAlignment) + 36
    frame #16: 0x00000001071ea6dc FridaGadget.dylibv8::internal::Deserializer<v8::internal::Isolate>::ReadObject(v8::internal::SnapshotSpace) + 112
    frame #17: 0x00000001071ebb54 FridaGadget.dylibint v8::internal::Deserializer<v8::internal::Isolate>::ReadSingleBytecodeData<v8::internal::SlotAccessorForRootSlots>(unsigned char, v8::internal::SlotAccessorForRootSlots) + 240

For gadget, a workaround would be to set the code signing policy to required.

This change forces --jitless for said platforms and resolves the issue.

[oleavr]

Thanks, great catch! I'm afraid this papers over the underlying issue though. V8 supports W^X systems too these days, so something is wrong with our V8 integration (GumV8Platform), how we configure V8, or perhaps some codepath in V8 that's macOS-only when it should be made more broad. I'll leave this open for now, as someday I'd like to take a stab at fixing the underlying issue -- and if it proves too involved we can merge this as a stop-gap. I'm hoping we can go straight to fixing it though as running V8 without a JIT eliminates its main strength compared to QuickJS.

[hexploitable]

Thanks, great catch! I'm afraid this papers over the underlying issue though. V8 supports W^X systems too these days, so something is wrong with our V8 integration (GumV8Platform), how we configure V8, or perhaps some codepath in V8 that's macOS-only when it should be made more broad. I'll leave this open for now, as someday I'd like to take a stab at fixing the underlying issue -- and if it proves too involved we can merge this as a stop-gap. I'm hoping we can go straight to fixing it though as running V8 without a JIT eliminates its main strength compared to QuickJS.

Fair! I was traveling these last 3 weeks but will try to find time to go a little further down the rabbit hole soon.