Conversation

Replying to and
Firefox is beyond hope in terms of hardening due to all the undefined behavior incompatible with mitigations, but in this case they're taking things even further and blocking improvements to the OS. They are literally overwriting a portion of libc with their hard-wired code...
1
2
Replying to and
I love how they even go out of the way to provide their own sigaltstack without a guard page, even though the base system already provides one with a guard page: github.com/mozilla/gecko- The code all insanity: github.com/mozilla/gecko- It comes up as an issue again and again.
1
3
Replying to and
Oh, and since they load it like this, their code ends up as dirty pages in memory instead of having on-demand paging from shared objects on the filesystem either in the apk (uncompressed) or in the directory of automatically extracted libraries / executables (compressed in apk).
1
Replying to and
Transmission of an apk is compressed so having a library uncompressed in the apk like Chromium doesn't waste bandwidth. The apk uses a bit more space on the device, but less than having it both compressed in the apk and extracted alongside it. Firefox's design choice is terrible.
1
I'll make sure to test it, It's likely still an issue since the problematic linker is part of Gecko rather than the Fennec frontend replaced by Fenix. It's a (bad) design choice and not something I'd feel comfortable reporting as an issue. They knew it was awful when they did it.
2
1
Test the new browser - if you see the issue, open an issue; I have seen GeckoView bugs being spawned from reports in Fenix, so they are willing to go back to the drawing board on things - it may not be prioritized, but don't let this conversation go to waste!
1