It won't have any other privacy and security improvements until further work is funded. I won't be fixing all of the upstream bugs uncovered by the hardened allocator myself so it will probably have a lot of issues for the time being. It will have a bare minimum set of changes.
Conversation
The manifest for this will be at github.com/AndroidHardeni. I haven't pushed the hardened malloc integration yet, but I started pushing the minimal set of changes for proper AOSP builds. For example, fixing ro.product.model is needed for the Auditor app to work among other things.
1
1
2
If there was funding for making production hardened AOSP builds, progress could be made on chipping away at upstream bugs uncovered by the hardened malloc implementation. There could also be official releases with automatic updates and proper CTS + VTS testing for each release.
1
2
I won't be expanding it into a broader project without the appropriate funding / resources though. The scope is limited to integrating the hardened malloc implementation into AOSP and setting up proper builds of that. It won't be very usable/useful without fixing uncovered bugs.
1
2
Simply doing all the debugging and release engineering necessary for production releases is a huge amount of work without even adding more privacy/security features and needs funding. It's too much work for one person unless it's their entire job, and I won't do it alone again.
2
3
Replying to
I am working on an reproducible build/sign/release system for Pixel 3 devices: github.com/hashbang/os
I plan on incorperating your work incrementally. Feel free to reach out if you want to collaborate at all, else just keep open sourcing stuff and I'll keep doing my thing :)
1
1
Replying to
Using those driver packages won't provide fully functional builds and will break verified boot and some other security features. Most of the components in the vendor image are open source too, so if you want to build what you can from source you need to assemble it yourself.
2
They merged everything needed for reproducible builds upstream for Linux, Chromium and AOSP so it's straightforward. Making production builds of AOSP with all the security features intact is more involved but the work has been done for Pixels and other devices don't support it.
1
Funding and collaboration is needed for implementing and maintaining substantial privacy and security improvements for AOSP. Release engineering is difficult because of the time investment required for testing and then debugging the issues that are uncovered by the features.
2
Replying to
I have enough funding for build servers and image hosting.
Also have a few willing testers. As long as the scope is -only- pixel/p devices right now this is looking fairly maintainable. Adding in all your patches ofc will take more test devices and a test channel but feasible.
1
Replying to
You aren't running the CTS and investigating all the issues it uncovers though. Building AOSP with reproducible builds is easy. It already exists and builds fine as is. Testing each release is time consuming and there are issues to investigate before even implementing features.
Implementing substantial privacy and security improvements leads to spending enormous amounts of time investigating the test failures, determining why there's a failure and debugging / fixing the issues that are identified. Exploit mitigations uncover lots of latent bugs.
1
Replying to
I have no illusions I can do it all myself :) Hopefully I can learn enough to be useful on the malloc hardening side once I have a stable vanillaish AOSP sign/build/release/host/update stack. If nothing else a pipeline to deploy patches/builds to testers will be a start.
Replying to
if you can point me to your general CTS workflow I would love to try to replicate it.