Transition to using 16 KB page sizes for Android apps and games

I am not familiar with Android, but Linux ELF binaries that specify 4KB alignment will not work on systems with 16KB page sizes, since the ELF interpreter will refuse to load them. This hit me recently when trying to run a 32-bit binary on a Linux ARM system that had 16KB size pages, since the 32-bit OpenSSL libraries specified 4KB alignment. Presumably, this was done for maximizing entropy available to ASLR, but it breaks the binaries when the page size increases.

In any case, I assume that there is something similar affecting Android.

Page size impacts page permissions; it's not a matter of wasting 12k, it's that with 4kb pages you're allowed to have a consecutive 8kb region with different permissions. 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.

> 16kb pages can't do that without segfaulting every time memory is used "wrong", and trying to fix that up transparently would be a nightmare.

I would natively imagine the kernel could trap that and remap on the fly, at the tiny cost of murdering performance. Is that untrue, or is the perf so bad that it's not worth it?

Anything which involves the kernel tracking permissions at 4k granularity despite using larger pages is just going to be worse in every way than using 4k pages.

It depends on how much of a program actually triggers the failure case, so you can't answer in the abstract.

In the worst case, ~every memory access causes the kernel to need to fix it, causing every memory access to be several orders of magnitude worse (e.g. a hot cache hit vs trapping into kernel, wiping caches, at the very least hundreds more accesses).

EDIT: I see you suggested remapping the page permissions. Maybe that helps! But maybe it adds the cost of the remapping onto the worst case, e.g. the first 4kb are instructions that write into the second 4kb.

As a user not involved in android or linux development: I don't care. Fix it. You just don't break the entire ecosystem of unmaintained apps for a 3% performance improvement.

We maintained win32-x86 executable compatibility for decades. Keeping things working might require some sort of emulation layer, and it might impact performance substantially, and that's fine. I can accept that.

"Everything just stops working" is not an option for a real operating system. I don't expect to put my workshop tools away and wake up in the morning to find the toolchest manufacturer sent them to the landfill because they didn't efficiently fit their new drawers.

One of the areas that Android is common in that I couldn't possibly recommend is home automation. Your light switches are 50-year purchases. Odds that the app based light switches are working in five years are 50/50... Compound odds of longer are miniscule.

Is anything industrial is going to be built on Android. There are no ATM's, no manufacturing CNC machines etc. One my say everything that runs on Android is throw away. It is only recently Samsung and Google started to aim at 7 year life spans. At 7 years for an industrial piece of equipment, I may not have even paid it off as yet, then again is the software on these things even updated?

Point of sale systems, like Toast. Media systems on airplanes. Infotainment systems in cars.

In fact, NCR does sell an Android-based ATM solution. [1]

Android is actually used somewhat widely in embedded systems that need to provide a nice GUI to the user.

[1]: https://www.zdnet.com/article/ncr-launches-kalpana-an-androi...

I think most apps are written in Java, and according to the blog post will not be affected.

It's only the apps written in c++ that need to be compiled, and those are probably large games and heavily performance critical apps.

That's a valid point, but isn't memory protection the only common user-visible effect of changed page sizes? It would seem most apps which do not use write-protected memory would be unaffected.

I think the most immediate problem would be ELF segments that aren't 16kb aligned. Code will abut data, you can't add a gap without breaking offsets inside the ELF, and you'll induce the segfault during every write to a global at the start of the writable code, or executing code at the end of the code segment.

A less safe option would be for permissions to be a union in that region, as code rarely depends on a permission being absent. That would be quite the security hole though.

Fortunately, like a truly embedded system, those are usually completely independent of Google or its app store.

Checking some random apps on my phone, it's very much not just games, and not just apps you'd naively suspect of being "heavily performance critical", either.

I suspect that code reuse of existing libraries not written in Java is another important use case.