Different page size support

[Sadoon-AlBader]

On arm64, make sure your kernel is configured to use 4k pages since we haven't yet added support for 16k and 64k pages. The kernel also has to be configured to use 4 level page tables for the full 48 bit address space instead of only having a 39 bit address space for the default hardened_malloc configuration. It's possible to reduce the class region size substantially to make a 39 bit address space workable but the defaults won't work.

Are there any plans to support larger page sizes? I have done some rudimentary testing on Debian 12 ppc64el by manually setting the page size in pages.h to 65536 and disabling the static_assert in h_malloc.c to see if things break ( I am adventurous :P )

Running simple programs seems everything works fine, and using "make test" also produces no errors.

I will gladly do testing or work on supporting larger page sizes if possible.

EDIT: Even chromium seems to run fine, I hope I didn't corrupt my profile.

[thestinger]

The size classes need to be redone for a larger page size. It will be incredibly inefficient doing it that way without redoing it. It would require larger bitmaps for the smallest size classes too.

[Sadoon-AlBader]

The size classes need to be redone for a larger page size. It will be incredibly inefficient doing it that way without redoing it. It would require larger bitmaps for the smallest size classes too.

Ah so it's less of an issue of it breaking software and more of it being inefficient this way?

[thestinger]

It's not set up for pages of that size. For example, 16 byte allocations are placed in a slab with 256 slots, which is 4096 bytes. The slab size will be rounded up to 65536 but only the first 4096 bytes will be used. For one thing, all the slot counts need to be redone, but 256 is currently the maximum number of slots with the current implementation. Replacing the array of 4x 64-bit integers with an array of 64x 64-bit integers is not a reasonable approach. It would need to use a multi-level bitmap or another approach.

[Sadoon-AlBader]

It's not set up for pages of that size. For example, 16 byte allocations are placed in a slab with 256 slots, which is 4096 bytes. The slab size will be rounded up to 65536 but only the first 4096 bytes will be used. For one thing, all the slot counts need to be redone, but 256 is currently the maximum number of slots with the current implementation. Replacing the array of 4x 64-bit integers with an array of 64x 64-bit integers is not a reasonable approach. It would need to use a multi-level bitmap or another approach.

That's quite a bit beyond my knowledge, and it does sound like it would need a rewrite. Thanks for the explanation and quick reply :)

[Sadoon-AlBader]

For what it's worth, I tried using the same ppc64el machine with Debian 12 on a 4K kernel to see if things work and they seem to do. Everything is working as expected, even the single app I have that crashes under x86_64 seems to crash here :p

If this helps this is my environment: Debian 12 with kernel 6.1.34, stock debian .config except 4K page sizes. hardened_malloc applied systemwide with the /etc/ld.so.preload method. vm.max_map_count set to 1048576 KDE desktop (Wayland) with patched QTWebEngine to run apps that depend on it (isn't shipped by default on POWER) Chromium, Kmail, Neochat, KeePassXC, Elisa, KMyMoney (the only crash as I mentioned), Calibre 5 (backported from Bullseye) I use a few others here and there but this is just to verify that they work.

The only thing that needs a change in the code is the Makefile to support -mcpu=native instead of -march=native since -march isn't supported on POWER

I'll send a tiny patch that checks if the system is POWER to use -mcpu instead of -march

Thanks again for this awesome code!

[ZerdoX-x]

As an Asahi Linux user I would really love to see support of 16k pages <3 Thank you for this project.

[thestinger]

It will only happen if a contributor works on it. We have no use for it in GrapheneOS.

[Andarwinux]

Android seems to be adding 16K page support in the future. https://android-review.googlesource.com/q/topic:%2216k_dev_ui%22