Conversation
Replying to
Check out this insanity: github.com/mozilla/gecko-. The normal choices are a library being extracted to the file system or having it mapped directly from the apk by having it uncompressed. Instead, Firefox uses lazy loading by intercepting segfaults when libraries are used.
2
1
2
Replying to
The latter kinda makes sense because the particular OS is so broken (vendor libs that call signal) but yes it's stupid that they're doing it to begin with.
1
Replying to
The library they're talking about is a cross-platform GPU driver, and GPU drivers are in general full of insane code. They like setting up all kinds of trampolines and alternate stack shenanigans so they are full of hard-wired hacks just like Firefox, which often conflict.
Something else that comes to mind is libffi. It implements FFI via a JIT compiler generating trampolines, and they have hard-wired support for SELinux execmem where they work around support for dynamic code generating being disallowed in-memory by doing it via /tmp. Yet...
1
... a proper policy will disallow doing it via the filesystem in any way too. Only something like a package manager generally actually needs to expose the attack surface of being able to create files which could be executed. They could definitely handle normal cases without JIT.
1
Show replies
Replying to
Sandbox that shit. Put it in its own process and its own fucking namespace and IPC it all.
1
1
Replying to
Chromium has an isolated GPU process and I've wanted to replicate that as a generic feature for all Android apps including Chromium on Android. Fortunately, the vast majority of the code/complexity for GPU drivers is in userspace libs, not their kernel drivers. One good thing.
1