Daniel Micay on Twitter: "@Ingolf_He @RichFelker @firefox 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." / Twitter

This 💩 is exhibit A for why there is no __MUSL__. github.com/erlang/otp/blo

2

3

Feb 25, 2019

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

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

Replying to

why won't you fix this madness?

1

Replying to

and

Firefox (fennec) is in semi-maintenance mode -- you should check to see whether Fenix has the same behavior and report it as an issue if so. github.com/mozilla-mobile tools.taskcluster.net/index/project.

2

1

2

Replying to

and

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.

5:35 AM · Feb 25, 2019Twitter Web Client

Replying to

Chromium took a better approach and their out-of-tree linker was eventually replaced with support for mapping libraries directly from an apk in Android's standard linker. Firefox could use it, but they may not want to bother until the oldest Android versions they support have it.

1

Replying to

Chromium uses separate build targets for modern Android versions so they can take more modern approaches despite supporting the older platform. That's how they're able to avoid having separate Chromium WebView and Chrome apps shipped on current devices. It's built as one library.

Replying to

and

Pretty sure the Fenix team is in your town -- maybe you can reach out to them and give them an earful in person. ;)

2

1

Replying to

and

I probably don't have many issues with the new frontend. It's the aging Gecko codebase that's a disaster. The old Firefox Android frontend was never a problem for me either despite having a legacy where they started out with a non-native toolkit / framework and moved towards it.

1

Show replies

Conversation