Conversation

Nov 1, 2018

I need a Pixel 3 for advancing my mobile security research. I don't have access to a current generation mobile device with a Snapdragon 845, the Linux 4.9 LTS with CFI and a StrongBox keymaster implementation. Bitcoin address for contributing: 34J5mcUveTUr99ZNB2SnFxCPFjXQCAxyuB.

Show this thread

hardened_malloc/README.md at main · GrapheneOS/hardened_malloc

In my experience, many device-specific memory corruption bugs are uncovered by using a memory allocator less friendly to memory corruption. The allocator isn't specifically intended for finding bugs (github.com/AndroidHardeni), so it can be painful to surface so many latent bugs.

github.com

Hardened allocator designed for modern systems. It has integration into Android's Bionic libc and can be used externally with musl and glibc as a dynamic library for use on other Linux-base...

Few of these discovered bugs are security issues but rather latent memory corruption occurring during regular use. Some is quite concerning even without it being a clear security issue though and it needs to be worked through to be able to use the hardened malloc implementation.

Portable AOSP code is much more heavily tested with ASan than the desktop Linux stack so it's easier to deploy these features for real. However, device-specific code on both platforms is much more problematic, particularly for mobile devices. It's a steady stream of new bugs too.

It's one of the main reasons that hardened builds of AOSP aren't sustainable without a team of developers. The mitigations uncover too many issues and most of the time ends up being spent resolving upstream bugs and application bugs rather than actually doing more hardening work.

These problems come and go between releases, particularly major releases. It's a huge part of the burden of porting to each new major release. It ends up being mandatory to move to major releases quickly too, since otherwise full security updates wouldn't be available anymore.