SELinux W^X denies exec-mapping app_data files and execveat on memfds
(no execute_no_trans, verified on API 35), but mmap PROT_EXEC on memfds
stays allowed - the class ART JIT rides on. Patch musl's map_library to
probe exec-mapping and, when refused, copy the library fd into an
executable memfd and map from there. One choke point covers the main
binary, DT_NEEDED deps, and dlopen, so the whole Python process tree
crosses the gate. A probe-first design keeps unrestricted environments
(generated APKs, targetSdk 28) on the zero-overhead direct path.
Ship the linker as a buildMuslBridge Gradle task: download the musl
1.2.5 tarball, apply scripts/patches, cross-compile with the NDK clang
toolchain (arm64-v8a + x86_64, LIBCC=compiler-rt builtins, x86_80 shim
for the routines NDK drops), strip into generated jniLibs - same
generated-artifact pattern as go_exec_loader, nothing binary committed.
resolveMuslLinker's native-first priority routes every launch path
(server, pip wrapper, sitecustomize rewrites) onto the patched linker
with no path changes; Python gates become canExec || hasMuslExecBridge.
Also aligns RuntimeExecPolicy's class doc with the #550 finding:
memfd-execveat loaders do NOT bypass W^X.
Fixes#589
Co-authored-by: shiaho <222622008+shiaho777@users.noreply.github.com>
shiaho
fa55accc44