No, it's very common. It's widely used in garbage collectors (instead of write barriers) and JIT compilers (for changing the code and also just for halting code execution) among other places. It's so common that userfaultfd was added as a better approach:
man7.org/linux/man-page
Conversation
Firefox also has a custom linker using this. On Android, the traditional officially supported approach to native libraries has them stored compressed in the apk and automatically extracted by the package manager to a library directory not writable by the application.
1
2
The more modern officially supported approach leaves them uncompressed in the apk (which only impacts installed size, since apk downloads should be compressed due to this approach for various kinds of resources, etc.) and aligned to page size. The linker knows how to map those.
1
Firefox stores the libraries compressed using a path not extracted as native libraries by the package manager. Instead, they manually extract / decompress the libraries. On low-memory ones, they put them in app data. On high-memory ones, they extract them directly into memory.
1
The insane part is that they use some nasty hacks to perform this extraction / decompression lazily. They catch segmentation faults from attempts to use the libraries and then map them in to those locations on demand, either paged from app data (low mem) or as dirty pages...
1
Chromium takes the officially supported approach of having them stored aligned / uncompressed in the apk and mapped directly from there. In fact, that was originally created for Chromium in a custom "crazy_linker" (doesn't deserve that name when you look at what Firefox does).
1
They added it as an officially supported approach to the OS as part of the standard linker, and Chromium moved to using that instead of crazy_linker. The real crazy linker is the Firefox GeckoLinker though. It's insane. It even monkey patches functions in libc to hijack them.
2
3
Sources for this monstrosity are at hg.mozilla.org/mozilla-centra. Here's their function for monkey patching libc: hg.mozilla.org/mozilla-centra. Below that, you can see where they catch segfaults and trigger the library loading. They also measure signal latency to see if it's worth doing.
1
1
2
They include an environment variable to disable the on-demand library loading, and I used to need to set that to avoid incompatibilities, but the libraries still end as dirty pages in memory immediately, or extracted into app data, which is also wasteful too and has bad security.
1
1
Since then not only is Firefox incompatible with w^x in memory (and I mean proper w^x where rw -> rx transitions aren't allowed), but also app data, so a file write vulnerability becomes native code exec. Their extension signing would actually be useful for that if done right...
If you can't tell, I have a personal vendetta against this code because it has wasted so much of my time at this point... and I find the entire concept of it horrible and unnecessary. I can't deny shipping compressed libs and decompressing right into dirty pages saves storage...
4