Specifically the call to Protect(..., kReadExecute) (which calls zx_vmar_protect) fails. This is why the FfiCallbackMetadata migration had to be reverted.
To fix this, VirtualMemory::DuplicateRX needs to be special cased, like it is for MacOS. In fact the implementation will be similar to the MacOS version. We'll need a call to zx_vmar_map, analogous to the vm_remap call, which remaps our executable memory over an existing writable memory. This requires special permissions that the ordinary VMO used by the rest of virtual_memory_fuchsia.cc doesn't have.
So we need the VMO that is created when the embedder loads the app's .so file in executable mode. At the moment the flutter embedder just discards this VMO, but we need to plumb it though Dart_Initialize to VirtualMemory.
cc @rmacnak-google
Specifically the call to
Protect(..., kReadExecute)(which callszx_vmar_protect) fails. This is why theFfiCallbackMetadatamigration had to be reverted.To fix this,
VirtualMemory::DuplicateRXneeds to be special cased, like it is for MacOS. In fact the implementation will be similar to the MacOS version. We'll need a call tozx_vmar_map, analogous to thevm_remapcall, which remaps our executable memory over an existing writable memory. This requires special permissions that the ordinary VMO used by the rest of virtual_memory_fuchsia.cc doesn't have.So we need the VMO that is created when the embedder loads the app's .so file in executable mode. At the moment the flutter embedder just discards this VMO, but we need to plumb it though Dart_Initialize to VirtualMemory.
cc @rmacnak-google