sqlite3_connection_pool: support opening pools without executable-memory FFI callbacks

[laurens-pilot]

Summary

sqlite3_connection_pool currently requires the Dart VM to allocate executable memory whenever a pool is opened, even when native update hooks are disabled. This causes release/AOT Flutter applications to abort on GrapheneOS when the per-app Dynamic code loading from memory restriction is enabled.

This came up while investigating ente/ente#3436.

Root cause

RawSqliteConnectionPool.open unconditionally creates an initializer with:

NativeCallable<Pointer<InitializedPool> Function()>.isolateLocal(...)

Dart implements NativeCallable by allocating an FFI callback trampoline page and changing it from writable to executable (Dart VM source). GrapheneOS denies that mprotect operation when in-memory dynamic code loading is restricted, and the Dart VM terminates the process. The failure is fatal and cannot be caught by the application.

Setting PoolConnections(enableNativeUpdateHooks: false) does not avoid this requirement: It disables the SQLite update hooks, but the initializer NativeCallable is still constructed before pkg_sqlite3_connection_pool_open is called.

Requested behavior

Could pool initialization support an AOT path that does not dynamically allocate executable callback trampolines?

Two possible directions appear to be:

1. Use a statically compiled Pointer.fromFunction initializer backed by carefully scoped isolate-local initialization state.
2. Adjust the native API so the initialized connections/options can be passed without a Dart callback.

Ideally, open and openAsync would retain their current multi-isolate, exception propagation and cleanup behavior while working when new anonymous executable mappings are prohibited.

[simolus3]

Thanks for the report! I can reproduce the issue on Linux with a systemd-run --user --property=MemoryDenyWriteExecute=yes, so it should be easy to test locally without a full Flutter build.

Unfortunately, Pointer.fromFunction goes through the same path in the Dart VM as NativeCallable. So it looks like we'd have to avoid callbacks entirely. That complicates things somewhat, but it should be possible

[laurens-pilot]

Thank you for the fast response!

I just saw your comment here. Does that mean that the issue should now be resolved?

[simolus3]

I have just published version 0.2.9 of sqlite3_connection_pool, which includes that fix and should resolve this issue. Please let me know if you still run into issues on GrapheneOS with that version.

Setting PoolConnections(enableNativeUpdateHooks: false) does not avoid this requirement: It disables the SQLite update hooks, but the initializer NativeCallable is still constructed before pkg_sqlite3_connection_pool_open is called.

Just to be clear: These native update hooks are actually native (implemented in Rust) and from my testing, don't require Dart callbacks or mprotect. So you can keep them enabled if you need update notifications.

[laurens-pilot]

Thanks a lot for the quick fix!