I've published sample releases of AOSP 9 with the next generation hardened malloc implementation and some other changes at seamlessupdate.app. It's at the domain I registered for the Updater app for the time being since I don't have a name for the OS hardening project yet.
Conversation
What makes you motivated to implement the OpenBSD pattern over extending the default google/Linux one to counter memory corruption?, is the default implement ation that bad ? Can you give a real life exploit use case?
1
Replying to
If you're talking about the hardened memory allocator, the design is explained in github.com/AndroidHardeni including a list of the security properties it provides. A traditional allocator provides essentially zero of those security properties. It's not theoretical stuff either.
1
What is it that you're not understanding? I don't know what you mean by "implement the OpenBSD pattern" or "extending the default google/Linux one". The new allocator is not a port of OpenBSD malloc. The documentation explains that it's a successor to the previous port of it.
1
You cannot bolt on security to an allocator design like dlmalloc and end up with a truly hardened allocator. You end up with a weak design with a few security features like canaries and zero filling on free sprinkled on. It doesn't provide these important security properties.
The reason for not just porting and substantially extending OpenBSD malloc, which is an existing hardened allocator, is given in the documentation. A clean start was required to gain security, performance and soon scalability advantages from the abundant address space on 64-bit.
1
It's also explicitly aimed at hardening in production, rather than having a mixed purpose like OpenBSD malloc split between bug discovery and hardening. Solely focusing on exploit mitigation changes the approach to various aspects of the design, and that's covered in the README.
1
Show replies