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

I can understand the desire for google to want devs to recompile their apps, but I don't see the need to dump old apps from the app store... who cares if an old app that works wastes 12k if it only needs a single 4k page?

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.

Apps that expect 4K pages will try to enforce memory protections at that granularity.

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?

"but I don't see the need to dump old apps from the app store"

They literally remove almost 50% total android app earlier this year, they clearly devoted to quality and security

Google already dumps old apps from store for no reason whatsoever:

https://android-developers.googleblog.com/2022/04/expanding-...

You have to update an application every year, even if it is just meaningless version bump. Otherwise it will be removed after 2 years. Despite saying that this policy is required to ensure user security, several recent Android releases didn't have any corresponding major security changes.

> I can understand the desire for google to want devs to recompile their apps, but I don't see the need to dump old apps from the app store

It could be that Google explicitly wants to dump un(der) maintained apps. Sure some might be clean and basic utilities that will work till the end of time, but many are probably abandonware or crummy demos and hello-world apps that look old and dated. They went on a whole purge recently already.

The App Store market is changing as Google/Apple grapple with efforts to end their monopolies. Maybe they're seeing that change and trying to use their dying advantage to frame themselves as the curated and reputable stores with high-quality maintained and up to date apps. When distribution is available from other places, they can chose their customers.

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.

They already force apps to update to new APIs every couple of years, it was the only way to stop developers to keep using deprecated stuff.

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...

What if you have a data structure that straddles the 4k boundary?

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.