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
Replying to
the new driver packages alone yielded me builds where all hardware seemingly works fine. Been painless so far. Working on verified boot and and a hashed manifest update system atm. Next is a system to publish signed builds and adapt your Updater to fetch them.
1
Replying to
Appears to work is a lot different than fully working. If you run the Compatibility Test Suite you'll see that what they provide it far from working properly. You could also just try using telephony features and you'll probably be able to find a lot of problems without the tests.
1
Replying to
LTE, BT, Wifi, screen, touch, audio etc work. Phone calls work but no phone audio. Will investigate compatibility suite. Going to try implementing phone audio fix from here: github.com/dan-v/rattlesn
1
Replying to
CTS will uncover much more than light manual testing. It's a very large test suite covering a broad set of APIs accessible via adb and apps including device managers. There's also the VTS for privileged testing but the CTS is already a lot of test coverage.
Replying to
1
Replying to
There's also the VTS but it's best to start with the CTS since it works with normal production user builds via adb and app level access including testing device managers, etc. It doesn't require privileged access and explicitly requires production user builds to pass the suite.
1
Show replies